From duerst@it.aoyama.ac.jp Fri May 1 00:18:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBF23A6BFA for ; Fri, 1 May 2009 00:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG83keDN+QD1 for ; Fri, 1 May 2009 00:18:12 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id E73CC3A6E70 for ; Fri, 1 May 2009 00:18:11 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n417JX3Y004254 for ; Fri, 1 May 2009 16:19:33 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 43a8_6b4c0c88_3620_11de_aa52_001d0969ab06; Fri, 01 May 2009 16:19:33 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47011) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 1 May 2009 16:18:23 +0900 Message-ID: <49FAA279.4070008@it.aoyama.ac.jp> Date: Fri, 01 May 2009 16:19:21 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: "Henry S. Thompson" Subject: Re: A new RFC for Web Addresses/Hypertext References: Background wrt LEIRIs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: public-iri@w3.org, Lisa Dusseault , www-tag@w3.org, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 07:18:14 -0000 Hello Henry, Many thanks for this very good overview. I'm cross-posting this to the IRI list (public-iri@w3.org) because Lisa at one point proposed to have this kind of discussion there, as well as to the Apps Discuss list (discuss@apps.ietf.org) to reach out to the relevant people in the IETF. I have also copied Lisa and Alex directly. I guess this is overall a bit too agressive of a cross-posting (but please tell me if you think I have missed somebody important). However, I hope we can converge quickly on where to move forward with what bits of the discussion/work. On 2009/04/29 0:31, Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > There are currently five documents in this space (that I am aware of): > > [URI] The current RFC governing URIs: > http://tools.ietf.org/html/rfc3986 > > [IRI] The current RFC governing IRIs: > http://tools.ietf.org/html/rfc3987 > > [IRI-BIS] The most recent draft of a planned update for the RFC > governing IRIs: > http://tools.ietf.org/html/draft-duerst-iri-bis-04 > > [LEIRI] A W3C Note defining Legacy Extended IRIs (extracted from [IRI-BIS]): > http://www.w3.org/TR/leiri/ > > [WEBADDR] A preliminary draft of a possible RFC for Web Addresses > (extracted from HTML5 [1]): > http://www.w3.org/html/wg/href/draft.html [not yet in RFC format, > converted version expected > RSN] > > On the TAG telcon of 2009-04-17, there was some sense that this is too > many specs in the same space. . . Agreed. > In order to contextualize and perhaps stimulate a possible effort to > seek a rationalization here, here's _my_ understanding of how we got > here. > > [URI] is the mature stage of a spec. which has been revised a number > of times. It carries a certain amount of historical baggage with > it, particularly its restriction to 7-bit characters, but that also > ensures wide interoperability and preserves access to legacy > applications. > > [IRI] was intended to address the needs of the expanding Internet > and Web community, allowing most of Unicode into most parts of IRIs. > Rather than require upgrades in a wide range of applications and > uses, it did not set up IRIs as a _replacement_ for URIs across the > board, but as a _complement_ to URIs. It therefore included an > explicit trancoding algorithm, for converting IRIs to URIs. > > [IRI-BIS] was initiated by the editors of [IRI] to correct several > errata to [IRI] and to address the exclusion from [IRI] of certain > characters and character ranges. Yes. In that sense, it is not a separate document from [IRI], just an update. That's very usual for IETF work, a bit less for W3C work if one looks only at Recommendations. So the effective number of documents is down from five to four. > [LEIRI] had its origins in the XML family of W3C specifications. > The XML specification itself [2], as well as a number of other > XML-related specifications (including XML Base, XML Schema, XPointer > Framework, XML Signature) all involve appeal to a process for > converting arbitrary strings which are intended to identify web > resources into URIs. They all incorporate more-or-less identical > prose excerpted from the XLink specification [3] which specifies how > this is to be done. > > The XML Core WG has long been unhappy with this state of affairs, > and the impending release of new editions of several of these specs > encouraged the WG to try to establish a single normative reference > for the concept of a string for identifying web resources in XML > documents and a process for converting them to URIs, which > acknowledged and built on the IRI specification. > > After drafting a document to serve this purpose, discussion with the > editors of [IRI-BIS] convinced all concerned that since a new > version of the IRI spec was already in progress, the best thing to > do, to respect precedent and to avoid unnecessary proliferation, was > to include the relevant definitions in [IRI-BIS], and in fact that > has been done [4]. Once it became apparent, however, that the > progress of [IRI-BIS] to Draft Standard status was likely to be > considerably delayed for reasons outside its editors' control, the > Core WG, with the agreement and co-operation of the editors of > [IRI-BIS], published [LEIRI] as a Working Group Note, so that the > re-issue of new editions of the relevant XML-familty specs could go > ahead. The intention is to issue a revision of [LEIRI] replacing > its contents with a reference to [IRI-BIS] as soon as [IRI-BIS] > becomes a Draft Standard. Yes. If that works out as described above (which I very much hope it will), then [LEIRI] will silently disappear. This would reduce the number of documents from four down to three. For the IETF side, I'd like to give a bit more background on LEIRIs. (see http://tools.ietf.org/html/draft-duerst-iri-bis-05#section-7) The main thing it does is to allow ASCII characters not allowed in URIs (and therefore not allowed in IRIs) back into what's otherwise essentially IRIs. The reason for why a number of XML specs (as listed above) differ from the IRI spec is that these specs adopted a very early and simple definition of IRIs (before the name IRI every existed). Later, when the IRI spec got tightened, these specs didn't want to follow this tightening because, while XML is very strict in what it accepts and what not, it doesn't want to retract promises once given. Another reason is that in XML, context and escaping conventions allow to include essentially any character, whereas for URIs and IRIs in general, this is not the case. > [WEBADDR] had in some ways a similar origin to [LEIRI], starting out > as a section of the HTML5 spec which addressed the process by which > existing browsers process strings to produce URIs which can be > dereferenced. Yes indeed. It changes a space to %20, the same as for LEIRIs. > It differs from [LEIRI] in the exact set of > characters which it escapes, Has anybody done an analysis? It seems to provide more detail about '[' and ']', escaping them depending on context. It could be that that's also necessary for LEIRIs. But "any occurrences of percent-encoding in the Web address will be double-encoded at this step." looks extremely scary. > and in the special handling it mandates > for the encoding of characters in the 'query' part of a URI. See more about that in my reply to Dan. > I am sure that the above summaries can be improved. In particular it > would be helpful have clear statements from their respective > authors/owners as to what the _requirements_ for the three new > documents ([IRI-BIS], [LEIRI] and [WEBADDR]) are. Only after we have > those would it make sense to turn to the question of whether we can > merge some or all of them. Okay, I'm usually not good at requirements, but for [IRI-BIS], they might look about as follows: - Be usable in general, not just in a specific context (such as XML, HTML,...) - Move to Draft Standard (or, if that turns out to not be possible, make sure we can do so on the next round. - Try to avoid fragmentation (terms such as "Human Readable Resource Identifiers" or "Web Addresses" or so can lead to quite a bit of confusion when the main goal is to deal with occasional legacy data that nobody should have produced anyway) - Include the (currently ongoing) update of IDNA (in particular affects section 4, Bidi, and references); that's what's currently holding back progress. Are these the things that you looked for when you said 'Requirements'? Or something else? Regards, Martin. > ht > > [1] http://dev.w3.org/html5/spec/Overview.html#urls > [2] http://www.w3.org/TR/xml/#dt-sysid > [3] http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators > [4] http://tools.ietf.org/html/draft-duerst-iri-bis-04#section-7 > - -- > Henry S. Thompson, School of Informatics, University of Edinburgh > Half-time member of W3C Team > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without it is forged spam] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFJ9yFQkjnJixAXWBoRAq5tAJwMb/0jpU6XwLbYNqyt2s4uNwTcQACdHx4B > F/J04oFFOeDHZLTT9Y0qkT0= > =f6+L > -----END PGP SIGNATURE----- > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Fri May 1 02:17:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140103A6DA1 for ; Fri, 1 May 2009 02:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.18 X-Spam-Level: * X-Spam-Status: No, score=1.18 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHbXC4-V2WDy for ; Fri, 1 May 2009 02:17:55 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id ACD5C3A6828 for ; Fri, 1 May 2009 02:17:40 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n419J2EU010271 for ; Fri, 1 May 2009 18:19:02 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 396e_118cc924_3631_11de_b041_0019b9e2b3d9; Fri, 01 May 2009 18:18:44 +0900 Received: from [IPv6:::1] ([133.2.210.1]:50519) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 1 May 2009 18:17:51 +0900 Message-ID: <49FABE79.9090307@it.aoyama.ac.jp> Date: Fri, 01 May 2009 18:18:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Dan Connolly Subject: Re: A new RFC for Web Addresses/Hypertext References: Background wrt LEIRIs References: <1241109226.8402.1139.camel@pav.lan> In-Reply-To: <1241109226.8402.1139.camel@pav.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Henry S. Thompson" , Apps Discuss , public-iri@w3.org, www-tag@w3.org, Lisa Dusseault X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 09:17:57 -0000 Hello Dan, [same added cross-postings as for previous mail.] On 2009/05/01 1:33, Dan Connolly wrote: > On Tue, 2009-04-28 at 16:31 +0100, Henry S. Thompson wrote: > [...] >> [WEBADDR] A preliminary draft of a possible RFC for Web Addresses >> (extracted from HTML5 [1]): >> http://www.w3.org/html/wg/href/draft.html [not yet in RFC format, >> converted version expected >> RSN] > [...] >> I am sure that the above summaries can be improved. In particular it >> would be helpful have clear statements from their respective >> authors/owners as to what the _requirements_ for the three new >> documents ([IRI-BIS], [LEIRI] and [WEBADDR]) are. Only after we have >> those would it make sense to turn to the question of whether we can >> merge some or all of them. > > Good question. I had hoped to document this in the draft by > now. > > One of the main requirements the design in [WEBADDR] takes > on is the non-western search engine problem. > > My understanding is that MS IE implemented a pre-IRI, > pre-unicode convention that form submission data should > go in the encoding that the form page was encoded in, > and the servers bought into this. I'm not sure this was IE, or Netscape. It was definitely very early in the game. It may already have been in some of the very early localized browsers. Or we may simply see it as a consequence of the fact that early browsers didn't do a conversion to Unicode, but kept data in the incoming encoding internally. For servers, it was also easy to adapt. On the assumption that most forms are sent from pages downloaded from the same server, it's easy to guess that a server working e.g. with EUC-JP would send its documents out in EUC-JP and would prefer getting its form data back in EUC-JP. So everything worked out relatively easily. HTML4 actually sanctions this behavior, as follows (see http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charset): >>>> The default value for this attribute is the reserved string "UNKNOWN". User agents may interpret this value as the character encoding that was used to transmit the document containing this FORM element. >>>> [btw, I have no idea what HTML5 does (or doesn't) do with accept-charset. For a long time, I thought it was dead, but then a few years ago, somebody told me that Mozilla had implemented it as part of their drive to become more standards-compliant.] > Mozilla tried to follow the IRI spec, but > "This breaks most sub-category links on a big greek on-line pc& gadget > shop > (http://www.e-shop.gr) rendering the site unusable." > https://bugzilla.mozilla.org/show_bug.cgi?id=284474 Unfortunately, the test page mentioned in that bug report is no longer available. It seems the domain expired. The issue of what to do with form submission for IRIs is actually one of the currently open issues for the IRI spec. Please see http://www.w3.org/International/iri-edit/#IRI-and-forms-107. At http://lists.w3.org/Archives/Public/public-iri/2007Jul/0000.html, I write "Where exactly is the boundary between these two behaviours?". What I mean is the following. Query parts exist: a) in "freestanding" IRIs, e.g. on a napkin, or when typed into the address field of a browser. b) in plain links, e.g. a@href, or img@src,... c) when created as part of a form submission It seems clear to me that for a), the only choice we have is to use UTF-8. Things such as "the page currently being displayed below" or "the encoding corresponding to the language version of the browser used" just don't make sense. It also seems clear to me that for c), using the encoding of the enclosing page is as reasonable a choice as it always was. This can be handled completely outside any IRI-related spec, and as far as I can see, seems to have been done already (see http://www.w3.org/TR/html5/forms.html#url-encoded-form-data, step 6.2.1; somebody needs to check the other submission methods, or confirm that they are irrelevant in this context.) [Oh, and accept-charset on forms is alive in HTML5, which means that there is always a way to indicated that you want the query part in UTF-8.] (see http://www.w3.org/TR/html5/forms.html#attr-form-accept-charset) I think it would be good to point out in a guideline to authors that a single value, preferrably UTF-8, is best.] So, b) is really the hard case. I definitely would have preferred if this went with UTF-8. The test page mentioned at https://bugzilla.mozilla.org/show_bug.cgi?id=284474 talks about pressing the submit button, not about pressing a link, so this may have been c) rather than b), but there is no way to check anymore. But it would probably make sense to recheck to make sure that it also applies to b) (or provide a pointer to a test that's still available). > I mostly made my peace with this in a June 2008 > discussion: > > Re: expected results for URI encoding tests? > http://lists.w3.org/Archives/Public/public-html/2008Jun/0369.html > > > p.s. I wish I could tell the story of the non-western > search engine problem/requirement more straightforwardly, > but I seem to have some sort of writer's block. Well, the problem is that when a server gets data (in a path component, and even more in a query part), they need to know what encoding it is to make sense of it and provide a reasonable answer. The reason why you are calling this the "search engine" problem may be that this problem is most prominent with search engines, because everybody agrees that people want to search in their language, not limited to US-ASCII. But it applies to any kind of query parts. Some search engines have their own way to passing encoding information, as an example, in http://www.google.com/search?q=%E9%9D%92%E5%B1%B1&ie=utf-8&oe=utf-8, "ie" indicates input encoding (i.e. what's sent to the server, and "oe" indicates output encoding (what should be sent back). Currently, I really don't understand why we more or less managed to move to "path part is UTF-8" from a time where path parts also where encoded in the encoding of the page that contained the link, whereas we haven't been able to make this transition for query parts. Is the reason that path parts are much more used independent of any electronic substrate that would allow to know the encoding (e.g. sides of buses)? Is the reason that "the encoding is the encoding of the containing page" was considered as being a defacto standard worth following for query parts, but just an implementation accident for path parts? Was it that RFC 3987 (and the drafts leading up to it) were not clear enough on how to handle query parts, and how this related to form submission? Is it that cgi scripts and the like (which usually process query parts) are much more difficult to change than the servers themselves (which usually process path parts)? Was it that IE made the decision, at a time where it could have gone both ways, but that now, there is much more i18n content, and it's harder to change? Regards, Martin. > Somebody else care to give it a try? TimBL? Ian? > Henri? > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From scampa.giovanni@gmail.com Fri May 1 02:36:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3E73A6C1A for ; Fri, 1 May 2009 02:36:39 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdUk15XHADoL for ; Fri, 1 May 2009 02:36:39 -0700 (PDT) Received: from mail-bw0-f175.google.com (mail-bw0-f175.google.com [209.85.218.175]) by core3.amsl.com (Postfix) with ESMTP id BFD0A28C194 for ; Fri, 1 May 2009 02:35:56 -0700 (PDT) Received: by bwz23 with SMTP id 23so2022089bwz.34 for ; Fri, 01 May 2009 02:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dZ3ChZoSzrMrFbtB7yYQBP9up/yDSHuoF7Ww+RZCQpg=; b=ldmPwExaQQClokgRuYj87VO6bWmHqZ4oMi9lNYsl7gXB3qOYwAFWa8Hg6T+6e85cvu Wo4ML8Igtjy8VQUXRy4cg9JLKM8ehSi+3tUsE7KJx0xWHgQ3E6ZYv0uduZXNKKMQ2Fo2 Fs9JmyLc4BSXJQZ3tV7KNabXNAm6Hxa8NMP8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WKPErDAnfpDINRcyVGpMGeat7/E1nppmXEZBlhhSq/JjIbsvXzIv+m+blhevApXDKe ACqkSpXXH2u0RdPR4YO9fPDVoLoLLLW5TikVmEs8CvXblt18shCddwIF9BZqEcskn0Nr KmUltZtkezgZNNCMIy4jXKuemr/PW9qV9GWGU= MIME-Version: 1.0 Received: by 10.204.100.10 with SMTP id w10mr2350638bkn.211.1241170639080; Fri, 01 May 2009 02:37:19 -0700 (PDT) In-Reply-To: <49FAA279.4070008@it.aoyama.ac.jp> References: <49FAA279.4070008@it.aoyama.ac.jp> Date: Fri, 1 May 2009 11:37:19 +0200 Message-ID: <65307430905010237g5da15da8ied60fc0912280cae@mail.gmail.com> Subject: Re: A new RFC for Web Addresses/Hypertext References: Background wrt LEIRIs From: Giovanni Campagna To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 May 2009 11:17:23 -0700 Cc: "Henry S. Thompson" , Apps Discuss , public-iri@w3.org, www-tag@w3.org, Lisa Dusseault X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 09:37:15 -0000 2009/5/1 "Martin J. D=FCrst" : > [...] > >> [WEBADDR] had in some ways a similar origin to [LEIRI], starting out >> =A0 as a section of the HTML5 spec which addressed the process by which >> =A0 existing browsers process strings to produce URIs which can be >> =A0 dereferenced. > > Yes indeed. It changes a space to %20, the same as for LEIRIs. > >> =A0 It differs from [LEIRI] in the exact set of >> =A0 characters which it escapes, > > Has anybody done an analysis? > > It seems to provide more detail about '[' and ']', escaping them dependin= g > on context. It could be that that's also necessary for LEIRIs. > > But "any occurrences of percent-encoding in the Web address will be > double-encoded at this step." looks extremely scary. It did such an analysis. You find it at (originally sent to the WHATWG mailing list, forwarded by Ian Hickson to www-archive@w3.org) Giovanni From samj@samj.net Sat May 2 02:07:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF22C3A6D82 for ; Sat, 2 May 2009 02:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv7WWegQrP2i for ; Sat, 2 May 2009 02:07:11 -0700 (PDT) Received: from mail-qy0-f127.google.com (mail-qy0-f127.google.com [209.85.221.127]) by core3.amsl.com (Postfix) with ESMTP id A8EA43A6D57 for ; Sat, 2 May 2009 02:06:13 -0700 (PDT) Received: by qyk33 with SMTP id 33so3705795qyk.29 for ; Sat, 02 May 2009 02:07:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.44.206 with SMTP id b14mr6484053vcf.55.1241255257185; Sat, 02 May 2009 02:07:37 -0700 (PDT) In-Reply-To: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> Date: Sat, 2 May 2009 11:07:37 +0200 Message-ID: <21606dcf0905020207i2a1cc0c6i2000443b27b87284@mail.gmail.com> Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Sam Johnston To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=0016e6469952ae1df20468ea42d1 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 09:07:15 -0000 --0016e6469952ae1df20468ea42d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brad, Sounds like a good idea, though I'd avoid using characters which are likely to break scripts/filters/etc. Perhaps something like "/__meta__" would be a better bet? Sam On Wed, Apr 29, 2009 at 7:50 PM, Brad Fitzpatrick wrote: > I'd like to discuss the proliferation of well-known URLs, notably the new > one proposed in draft-nottingham-site-meta-01. > > I talked to Eran Hammer-Lahav about this, but he suggested I bring it up > here: > > I object to the use of /host-meta for two reasons: > > 1) I feel that /host-meta is too casual of a name and prone to collisions= . > It matches /^[\w\-]+$/, which I think is a subset of a fair number of sit= es' > usernames. > > 2) There are already too many well-known URLs cluttering up the namespace= : > > /robots.txt > /favicon.ico > /crossdomain.xml > > We can't fix those, but rather than make another one (and don't kid > yourself: /host-meta won't be the last one) and make the situation worse,= I > propose we do the respectful thing and make a well-known directory to put > this and all future well-known files in. e.g.: > > /;well_known/host-meta > > i.e. put something ugly and weird in there, like a semicolon, to minimize > the chance that it interferes with people's existing URL structure. > > Hopefully when the next spec decides to add a new well-known URL, they pu= t > it under /;well_known/. "But host-meta is the final one, forever!", you > say. I doubt it. XRD will become pass=E9, or people will object to doin= g two > HTTP requests when they really want to do one, so yet another well-known = URL > will be born. Let's give it a future home now. > > Thoughts? > > - Brad > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --0016e6469952ae1df20468ea42d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brad,

Sounds like a good idea, though I'd avoid using characters= which are likely to break scripts/filters/etc.

Perhaps something li= ke "/__meta__" would be a better bet?

Sam

On Wed, Apr 29, 2009 at 7:50 PM, Brad Fitzpatrick <brad@danga.com> wrote:
I'd like to discuss the proliferation of well-known URLs, notably the n= ew one proposed in draft-nottingham-site-meta-01.

I talked to Eran H= ammer-Lahav about this, but he suggested I bring it up here:

I objec= t to the use of /host-meta for two reasons:

1) I feel that /host-meta is too casual of a name and prone to collisio= ns.=A0 It matches /^[\w\-]+$/, which I think is a subset of a fair number of sites' usern= ames.

2) There are already too many well-known URLs cluttering up th= e namespace:

/robots.txt
/favicon.ico
/crossdomain.xml

We can't fix= those, but rather than make another one (and don't kid yourself: /host-meta won't be the l= ast one) and make the situation worse, I propose we do the respectful thing and= make a well-known directory to put this and all future well-known files in.=A0 e.g.:

/;well_known/host-meta

i.e. put something ugly and weird in ther= e, like a semicolon, to minimize the chance that it interferes with people&= #39;s existing URL structure.

Hopefully when the next spec decides t= o add a new well-known URL, they put it under /;well_known/.=A0 "But h= ost-meta is the final one, forever!", you say.=A0 I doubt it.=A0 XRD w= ill become pass=E9, or people will object to doing two HTTP requests when t= hey really want to do one, so yet another well-known URL will be born.=A0 L= et's give it a future home now.

Thoughts?

- Brad


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


--0016e6469952ae1df20468ea42d1-- From mark@coactus.com Sat May 2 05:28:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9820B3A6807 for ; Sat, 2 May 2009 05:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=-2.745, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAlF8kaUDSYD for ; Sat, 2 May 2009 05:28:37 -0700 (PDT) Received: from mail-qy0-f127.google.com (mail-qy0-f127.google.com [209.85.221.127]) by core3.amsl.com (Postfix) with ESMTP id D210B3A684C for ; Sat, 2 May 2009 05:28:36 -0700 (PDT) Received: by qyk33 with SMTP id 33so3775317qyk.29 for ; Sat, 02 May 2009 05:30:00 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.229.82.81 with SMTP id a17mr2664950qcl.107.1241267400618; Sat, 02 May 2009 05:30:00 -0700 (PDT) In-Reply-To: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> Date: Sat, 2 May 2009 05:30:00 -0700 X-Google-Sender-Auth: b0305f20bd20c7a8 Message-ID: Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Mark Baker To: Brad Fitzpatrick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 12:28:37 -0000 On Wed, Apr 29, 2009 at 10:50 AM, Brad Fitzpatrick wrote: > I'd like to discuss the proliferation of well-known URLs, notably the new > one proposed in draft-nottingham-site-meta-01. > > I talked to Eran Hammer-Lahav about this, but he suggested I bring it up > here: > > I object to the use of /host-meta for two reasons: > > 1) I feel that /host-meta is too casual of a name and prone to collisions= . > It matches /^[\w\-]+$/, which I think is a subset of a fair number of sit= es' > usernames. Perhaps, but I don't see any cause for concern here; http://www.google.com/search?q=3Dinurl:host-meta > > 2) There are already too many well-known URLs cluttering up the namespace= : > > /robots.txt > /favicon.ico > /crossdomain.xml > > We can't fix those, but rather than make another one (and don't kid > yourself: /host-meta won't be the last one) I agree, but because there will be people who don't know about the protocol, and that will be the case no matter which protocol is used. > and make the situation worse, I > propose we do the respectful thing and make a well-known directory to put > this and all future well-known files in.=A0 e.g.: The Web doesn't have directories, it has URIs, and both what you describe, and what's in the draft, define a well known URI per domain. So I really don't see any practical difference here. Mark. From brad@fitzpat.com Sat May 2 09:09:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7813A69C0 for ; Sat, 2 May 2009 09:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN2n9h+t1zgu for ; Sat, 2 May 2009 09:09:50 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 5D3283A692F for ; Sat, 2 May 2009 09:09:49 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1901111rvb.49 for ; Sat, 02 May 2009 09:11:14 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.141.185.10 with SMTP id m10mr1352506rvp.32.1241280674352; Sat, 02 May 2009 09:11:14 -0700 (PDT) In-Reply-To: References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> Date: Sat, 2 May 2009 09:11:14 -0700 X-Google-Sender-Auth: 860aa608fd903998 Message-ID: <1076e6c00905020911v7420f4c2m9618272901cb321e@mail.gmail.com> Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Brad Fitzpatrick To: Mark Baker Content-Type: multipart/alternative; boundary=000e0cd28e84a94e4b0468f02d3f Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:09:51 -0000 --000e0cd28e84a94e4b0468f02d3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Sat, May 2, 2009 at 5:30 AM, Mark Baker wrote: > On Wed, Apr 29, 2009 at 10:50 AM, Brad Fitzpatrick wrote: > > I'd like to discuss the proliferation of well-known URLs, notably the new > > one proposed in draft-nottingham-site-meta-01. > > > > I talked to Eran Hammer-Lahav about this, but he suggested I bring it up > > here: > > > > I object to the use of /host-meta for two reasons: > > > > 1) I feel that /host-meta is too casual of a name and prone to > collisions. > > It matches /^[\w\-]+$/, which I think is a subset of a fair number of > sites' > > usernames. > > Perhaps, but I don't see any cause for concern here; > > http://www.google.com/search?q=inurl:host-meta Yet. But once we pick something easily-creatable, you'd see a lot more bogus ones, or you'd see resistance to people supporting it, because host-meta is already in the namespace that they use for other things. I'm not making up this concern: I'm already hearing that from people when I talk about having them implement this. > > > > 2) There are already too many well-known URLs cluttering up the > namespace: > > > > /robots.txt > > /favicon.ico > > /crossdomain.xml > > > > We can't fix those, but rather than make another one (and don't kid > > yourself: /host-meta won't be the last one) > > I agree, but because there will be people who don't know about the > protocol, and that will be the case no matter which protocol is used. I don't follow. I'm proposing a common prefix, not protocol, for well-known URIs cluttering up the namespace. Unrelated to host-meta, I want a company in the future that _needs_ to have their little file at the top-level of a domain to be able to follow in our footsteps and use /;wellknown/new-file.txt > > and make the situation worse, I > > propose we do the respectful thing and make a well-known directory to put > > this and all future well-known files in. e.g.: > > The Web doesn't have directories, it has URIs, Yes, thanks. :) I'm proposing that our well-known URI that we're creating here has a prefix which other well-known URIs in the future can share, to stop the build-up of well-known URIs in the namespace that sites have effectively allocated for other things, like users: http://twitter.com/host-meta http://profiles.google.com/host-meta http://identi.ca/host-meta Those don't exist at present, but it's not crazy to think there are sites out there where URLs like those could exist. > and both what you > describe, and what's in the draft, define a well known URI per domain. > So I really don't see any practical difference here. There's no functional difference. The difference is only not cluttering up people's namespaces. The practical difference is not annoying sites. --000e0cd28e84a94e4b0468f02d3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, May 2, 2009 at 5:30 AM, Mark Baker <disto= bj@acm.org> wrote:
On Wed, Apr 29, 2009 at 10:50 AM, Brad Fitzpatrick <brad@danga.com> wrote:
> I'd like to discuss the proliferation of well-known URLs, notably = the new
> one proposed in draft-nottingham-site-meta-01.
>
> I talked to Eran Hammer-Lahav about this, but he suggested I bring it = up
> here:
>
> I object to the use of /host-meta for two reasons:
>
> 1) I feel that /host-meta is too casual of a name and prone to collisi= ons.
> It matches /^[\w\-]+$/, which I think is a subset of a fair number of = sites'
> usernames.

Perhaps, but I don't see any cause for concern here;

http://www.google.com/search?q=3Dinurl:host-meta
<= br>
Yet. =C2=A0But once we pick something easily-creatable, you&#= 39;d see a lot more bogus ones, or you'd see resistance to people suppo= rting it, because host-meta is already in the namespace that they use for o= ther things. =C2=A0I'm not making up this concern: =C2=A0I'm alread= y hearing that from people when I talk about having them implement this.
=C2=A0
=
>
> 2) There are already too many well-known URLs cluttering up the namesp= ace:
>
> /robots.txt
> /favicon.ico
> /crossdomain.xml
>
> We can't fix those, but rather than make another one (and don'= t kid
> yourself: /host-meta won't be the last one)

I agree, but because there will be people who don't know about th= e
protocol, and that will be the case no matter which protocol is used.

I don't follow. =C2=A0I'm proposing a co= mmon prefix, not protocol, for well-known URIs cluttering up the namespace.= =C2=A0Unrelated to host-meta, I want a company in the future that _needs_ = to have their little file at the top-level of a domain to be able to follow= in our footsteps and use /;wellknown/new-file.txt

=C2=A0=C2=A0
> and make the situation worse, I
> propose we do the respectful thing and make a well-known directory to = put
> this and all future well-known files in.=C2=A0 e.g.:

The Web doesn't have directories, it has URIs,
<= br>
Yes, thanks. =C2=A0:) =C2=A0I'm proposing that our well-k= nown URI that we're creating here has a prefix which other well-known U= RIs in the future can share, to stop the build-up of well-known URIs in the= namespace that sites have effectively allocated for other things, like use= rs:

http://twitter.com/host-meta
http://profiles.goog= le.com/host-meta
http://ident= i.ca/host-meta

Those don't exist at present, but it's not crazy to think there= are sites out there where URLs like those could exist.
=C2=A0
= and both what you
describe, and what's in the draft, define a well known URI per domain.<= br> =C2=A0So I really don't see any practical difference here.
=

There's no functional difference.=C2=A0 The differe= nce is only not cluttering up people's namespaces.

The practical= difference is not annoying sites.

--000e0cd28e84a94e4b0468f02d3f-- From brad@fitzpat.com Sat May 2 09:12:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154C23A6945 for ; Sat, 2 May 2009 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAYRlknSgEKK for ; Sat, 2 May 2009 09:12:30 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 4428A3A6DF0 for ; Sat, 2 May 2009 09:11:41 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1901526rvb.49 for ; Sat, 02 May 2009 09:13:05 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.141.28.4 with SMTP id f4mr1465546rvj.37.1241280785799; Sat, 02 May 2009 09:13:05 -0700 (PDT) In-Reply-To: <21606dcf0905020207i2a1cc0c6i2000443b27b87284@mail.gmail.com> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <21606dcf0905020207i2a1cc0c6i2000443b27b87284@mail.gmail.com> Date: Sat, 2 May 2009 09:13:05 -0700 X-Google-Sender-Auth: e528ad9b73879ea4 Message-ID: <1076e6c00905020913r66341699t708020838e2e8fe2@mail.gmail.com> Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Brad Fitzpatrick To: Sam Johnston Content-Type: multipart/alternative; boundary=000e0cd179fc4ddb660468f034d2 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:12:31 -0000 --000e0cd179fc4ddb660468f034d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Sat, May 2, 2009 at 2:07 AM, Sam Johnston wrote: > Brad, > > Sounds like a good idea, though I'd avoid using characters which are likely > to break scripts/filters/etc. That's kinda the point. > Perhaps something like "/__meta__" would be a better bet? That's even worse than host-meta in the sense that it's more common of a username pattern (more sites allow "_" than "-" in a username). And one of my main concerns is the number of sites that give users a URL like site.com/USERNAME --000e0cd179fc4ddb660468f034d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, May 2, 2009 at 2:07 AM, Sam John= ston <samj@samj.net> wrote:
Brad,

Sounds like a good idea, though I'd avoid using characters= which are likely to break scripts/filters/etc.

That&#= 39;s kinda the point.
=C2=A0
Perhaps something like "/__meta__" would be a better bet?

--000e0cd179fc4ddb660468f034d2-- From eran@hueniverse.com Mon May 4 08:17:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7183A7069 for ; Mon, 4 May 2009 08:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-1.597, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0IukDBKQKGc for ; Mon, 4 May 2009 08:17:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2B1013A6A79 for ; Mon, 4 May 2009 08:17:03 -0700 (PDT) Received: (qmail 13927 invoked from network); 4 May 2009 15:18:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 May 2009 15:18:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 4 May 2009 08:18:17 -0700 From: Eran Hammer-Lahav To: Brad Fitzpatrick , Sam Johnston Date: Mon, 4 May 2009 08:18:17 -0700 Subject: RE: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Thread-Topic: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Thread-Index: AcnLQQORZaXbZIK7S1ewRnS5DlqTvgBig65Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343780AFFFCF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <21606dcf0905020207i2a1cc0c6i2000443b27b87284@mail.gmail.com> <1076e6c00905020913r66341699t708020838e2e8fe2@mail.gmail.com> In-Reply-To: <1076e6c00905020913r66341699t708020838e2e8fe2@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343780AFFFCFP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 15:17:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343780AFFFCFP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBtYWtlcyBzZW5zZSBidXQgSSBkb27igJl0IGhhdmUgc3Ryb25nIHZpZXdzIGhlcmUuIE15 IG9ubHkgY29uY2VybiBpcyB0byBnZXQgdGhpcyBhZG9wdGVkIGZvciBob3N0LW1ldGEgc28gd2hh dGV2ZXIgcHJvdmVzIHRvIGJlIHRoZSBwYXRoIG9mIGxlYXN0IHJlc2lzdGFuY2Ugd29ya3MgZm9y IG1lLg0KDQpPbiB0aGUgYnVzaW5lc3Mgb2YgdXNpbmcgb2RkIGNoYXJhY3RlcnMsIGlzbuKAmXQg Y2hvb3NpbmcgYW55IOKAmCov4oCZIHByZWZpeCBnb2luZyB0byBzb2x2ZSB5b3VyIGNvbmNlcm5z PyBObyBzaXRlIEkga25vdyBhbGxvd3MgdXNpbmcg4oCYL+KAmSBmb3IgdXNlcm5hbWVzLCBzaG9y dCBVUkxzLCBldGMuIEnigJltIGFmcmFpZCBtYWtpbmcgdGhlIHByZWZpeCDigJx1Z2x54oCdIHdp bGwgY2F1c2UgcGVvcGxlIG5vdCB0byB1c2UgaXQgYW5kIHdpbGwgbWFrZSBkb2N1bWVudGluZyBp dCBjb25mdXNpbmcgdG8gcGVvcGxlIHdobyB3aWxsIG5vdCBiZSBleHBlY3Rpbmcgc29tZXRoaW5n IGxpa2UgdGhhdC4NCg0KRUhMDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmFk IEZpdHpwYXRyaWNrDQpTZW50OiBTYXR1cmRheSwgTWF5IDAyLCAyMDA5IDk6MTMgQU0NClRvOiBT YW0gSm9obnN0b24NCkNjOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBPbiB0 aGUgcHJvbGlmZXJhdGlvbiBvZiB3ZWxsLWtub3duIFVSTHM7IGRyYWZ0LW5vdHRpbmdoYW0tc2l0 ZS1tZXRhLTAxDQoNCg0KT24gU2F0LCBNYXkgMiwgMjAwOSBhdCAyOjA3IEFNLCBTYW0gSm9obnN0 b24gPHNhbWpAc2Ftai5uZXQ8bWFpbHRvOnNhbWpAc2Ftai5uZXQ+PiB3cm90ZToNCkJyYWQsDQoN ClNvdW5kcyBsaWtlIGEgZ29vZCBpZGVhLCB0aG91Z2ggSSdkIGF2b2lkIHVzaW5nIGNoYXJhY3Rl cnMgd2hpY2ggYXJlIGxpa2VseSB0byBicmVhayBzY3JpcHRzL2ZpbHRlcnMvZXRjLg0KDQpUaGF0 J3Mga2luZGEgdGhlIHBvaW50Lg0KDQpQZXJoYXBzIHNvbWV0aGluZyBsaWtlICIvX19tZXRhX18i IHdvdWxkIGJlIGEgYmV0dGVyIGJldD8NCg0KVGhhdCdzIGV2ZW4gd29yc2UgdGhhbiBob3N0LW1l dGEgaW4gdGhlIHNlbnNlIHRoYXQgaXQncyBtb3JlIGNvbW1vbiBvZiBhIHVzZXJuYW1lIHBhdHRl cm4gKG1vcmUgc2l0ZXMgYWxsb3cgIl8iIHRoYW4gIi0iIGluIGEgdXNlcm5hbWUpLiAgQW5kIG9u ZSBvZiBteSBtYWluIGNvbmNlcm5zIGlzIHRoZSBudW1iZXIgb2Ygc2l0ZXMgdGhhdCBnaXZlIHVz ZXJzIGEgVVJMIGxpa2Ugc2l0ZS5jb20vVVNFUk5BTUU8aHR0cDovL3NpdGUuY29tL1VTRVJOQU1F Pg0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E72343780AFFFCFP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0K PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNl Y3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlRo aXMgbWFrZXMgc2Vuc2UgYnV0IEkgZG9u4oCZdCBoYXZlIHN0cm9uZyB2aWV3cyBoZXJlLiBNeSBv bmx5DQpjb25jZXJuIGlzIHRvIGdldCB0aGlzIGFkb3B0ZWQgZm9yIGhvc3QtbWV0YSBzbyB3aGF0 ZXZlciBwcm92ZXMgdG8gYmUgdGhlIHBhdGgNCm9mIGxlYXN0IHJlc2lzdGFuY2Ugd29ya3MgZm9y IG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+T24gdGhlIGJ1c2luZXNzIG9mIHVz aW5nIG9kZCBjaGFyYWN0ZXJzLCBpc27igJl0IGNob29zaW5nIGFueSDigJgqL+KAmQ0KcHJlZml4 IGdvaW5nIHRvIHNvbHZlIHlvdXIgY29uY2VybnM/IE5vIHNpdGUgSSBrbm93IGFsbG93cyB1c2lu ZyDigJgv4oCZIGZvcg0KdXNlcm5hbWVzLCBzaG9ydCBVUkxzLCBldGMuIEnigJltIGFmcmFpZCBt YWtpbmcgdGhlIHByZWZpeCDigJx1Z2x54oCdIHdpbGwgY2F1c2UNCnBlb3BsZSBub3QgdG8gdXNl IGl0IGFuZCB3aWxsIG1ha2UgZG9jdW1lbnRpbmcgaXQgY29uZnVzaW5nIHRvIHBlb3BsZSB3aG8g d2lsbA0Kbm90IGJlIGV4cGVjdGluZyBzb21ldGhpbmcgbGlrZSB0aGF0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6IzFGNDk3RCc+RUhMPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+DQphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFw cHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSA8Yj5Pbg0KQmVoYWxmIE9mIDwvYj5CcmFkIEZp dHpwYXRyaWNrPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXkgMDIsIDIwMDkgOToxMyBB TTxicj4NCjxiPlRvOjwvYj4gU2FtIEpvaG5zdG9uPGJyPg0KPGI+Q2M6PC9iPiBhcHBzLWRpc2N1 c3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE9uIHRoZSBwcm9saWZlcmF0aW9u IG9mIHdlbGwta25vd24gVVJMczsNCmRyYWZ0LW5vdHRpbmdoYW0tc2l0ZS1tZXRhLTAxPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD5PbiBTYXQsIE1heSAyLCAyMDA5IGF0IDI6MDcgQU0sIFNhbSBKb2huc3Rv biAmbHQ7PGENCmhyZWY9Im1haWx0bzpzYW1qQHNhbWoubmV0Ij5zYW1qQHNhbWoubmV0PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5CcmFkLDxicj4N Cjxicj4NClNvdW5kcyBsaWtlIGEgZ29vZCBpZGVhLCB0aG91Z2ggSSdkIGF2b2lkIHVzaW5nIGNo YXJhY3RlcnMgd2hpY2ggYXJlIGxpa2VseSB0bw0KYnJlYWsgc2NyaXB0cy9maWx0ZXJzL2V0Yy48 bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxicj4NClRoYXQn cyBraW5kYSB0aGUgcG9pbnQuPGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0K DQo8YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0Ow0KbWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5QZXJoYXBzIHNvbWV0aGluZyBs aWtlICZxdW90Oy9fX21ldGFfXyZxdW90OyB3b3VsZCBiZSBhDQpiZXR0ZXIgYmV0PzxvOnA+PC9v OnA+PC9wPg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj4NClRoYXQncyBldmVuIHdvcnNlIHRoYW4g aG9zdC1tZXRhIGluIHRoZSBzZW5zZSB0aGF0IGl0J3MgbW9yZSBjb21tb24gb2YgYQ0KdXNlcm5h bWUgcGF0dGVybiAobW9yZSBzaXRlcyBhbGxvdyAmcXVvdDtfJnF1b3Q7IHRoYW4gJnF1b3Q7LSZx dW90OyBpbiBhDQp1c2VybmFtZSkuJm5ic3A7IEFuZCBvbmUgb2YgbXkgbWFpbiBjb25jZXJucyBp cyB0aGUgbnVtYmVyIG9mIHNpdGVzIHRoYXQgZ2l2ZQ0KdXNlcnMgYSBVUkwgbGlrZSA8YSBocmVm PSJodHRwOi8vc2l0ZS5jb20vVVNFUk5BTUUiPnNpdGUuY29tL1VTRVJOQU1FPC9hPjxvOnA+PC9v OnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4N Cg== --_000_90C41DD21FB7C64BB94121FBBC2E72343780AFFFCFP3PW5EX1MB01E_-- From Nicolas.Williams@sun.com Mon May 4 09:24:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F3328C1C6 for ; Mon, 4 May 2009 09:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asT1yKjJqOn3 for ; Mon, 4 May 2009 09:24:22 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 0629B28C134 for ; Mon, 4 May 2009 09:24:22 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n44GPl1O012442 for ; Mon, 4 May 2009 16:25:48 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n44GPl4Z046779 for ; Mon, 4 May 2009 10:25:47 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n44G160n024802; Mon, 4 May 2009 11:01:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n44G15EM024801; Mon, 4 May 2009 11:01:05 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 4 May 2009 11:01:05 -0500 From: Nicolas Williams To: Brad Fitzpatrick Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Message-ID: <20090504160105.GB1500@Sun.COM> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <1076e6c00905020911v7420f4c2m9618272901cb321e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1076e6c00905020911v7420f4c2m9618272901cb321e@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:24:23 -0000 On Sat, May 02, 2009 at 09:11:14AM -0700, Brad Fitzpatrick wrote: > On Sat, May 2, 2009 at 5:30 AM, Mark Baker wrote: > > > 2) There are already too many well-known URLs cluttering up the > > namespace: > > > > > > /robots.txt > > > /favicon.ico > > > /crossdomain.xml > > > > > > We can't fix those, but rather than make another one (and don't kid > > > yourself: /host-meta won't be the last one) > > > > I agree, but because there will be people who don't know about the > > protocol, and that will be the case no matter which protocol is used. > > I don't follow. I'm proposing a common prefix, not protocol, for well-known > URIs cluttering up the namespace. Unrelated to host-meta, I want a company > in the future that _needs_ to have their little file at the top-level of a > domain to be able to follow in our footsteps and use > /;wellknown/new-file.txt The well-known prefix should be used for new things like robots.txt, host-meta, ... That relies on developers to get that right, but I think eventually enough will get it right for this to make a difference, thus this idea seems worthwhile. It would be nice to have a registry of well-known URI components. > > The Web doesn't have directories, it has URIs, > > Yes, thanks. :) I'm proposing that our well-known URI that we're creating > here has a prefix which other well-known URIs in the future can share, to > stop the build-up of well-known URIs in the namespace that sites have > effectively allocated for other things, like users: > > http://twitter.com/host-meta > http://profiles.google.com/host-meta > http://identi.ca/host-meta > > Those don't exist at present, but it's not crazy to think there are sites > out there where URLs like those could exist. Exactly. Why should some bright eyed developer come up with the Next Big Thing that steps all over some other peoples' URIs when said developer could use a reserved part of the namespace at no extra cost to themselves? Nico -- From Nicolas.Williams@sun.com Mon May 4 09:29:49 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349CC3A6D49 for ; Mon, 4 May 2009 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQifXkl83NxP for ; Mon, 4 May 2009 09:29:48 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 6AB913A6D16 for ; Mon, 4 May 2009 09:29:43 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n44GV9hJ014570 for ; Mon, 4 May 2009 16:31:09 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n44GV84j050885 for ; Mon, 4 May 2009 10:31:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n44G6VE1024810; Mon, 4 May 2009 11:06:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n44G6UFU024809; Mon, 4 May 2009 11:06:30 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 4 May 2009 11:06:30 -0500 From: Nicolas Williams To: Eran Hammer-Lahav Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Message-ID: <20090504160630.GC1500@Sun.COM> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <21606dcf0905020207i2a1cc0c6i2000443b27b87284@mail.gmail.com> <1076e6c00905020913r66341699t708020838e2e8fe2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343780AFFFCF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343780AFFFCF@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.7i Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:29:49 -0000 On Mon, May 04, 2009 at 08:18:17AM -0700, Eran Hammer-Lahav wrote: > This makes sense but I don’t have strong views here. My only concern > is to get this adopted for host-meta so whatever proves to be the path > of least resistance works for me. > > On the business of using odd characters, isn’t choosing any ‘*/’ > prefix going to solve your concerns? No site I know allows using ‘/’ > for usernames, short URLs, etc. I’m afraid making the prefix “ugly†> will cause people not to use it and will make documenting it confusing > to people who will not be expecting something like that. But sites do often allow users to have files, so "*/" falls down. From eran@hueniverse.com Mon May 4 09:43:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4163A6C16 for ; Mon, 4 May 2009 09:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9c9t1mctFjt for ; Mon, 4 May 2009 09:43:56 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B17B53A6B37 for ; Mon, 4 May 2009 09:43:56 -0700 (PDT) Received: (qmail 13863 invoked from network); 4 May 2009 16:45:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 May 2009 16:45:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 4 May 2009 09:44:58 -0700 From: Eran Hammer-Lahav To: Nicolas Williams Date: Mon, 4 May 2009 09:45:00 -0700 Subject: RE: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Thread-Topic: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Thread-Index: AcnM1K+uwVLRHGEyT0Gfjmk/8k/0egAArYrg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343780AFFFF3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <21606dcf0905020207i2a1cc0c6i2000443b27b87284@mail.gmail.com> <1076e6c00905020913r66341699t708020838e2e8fe2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343780AFFFCF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090504160630.GC1500@Sun.COM> In-Reply-To: <20090504160630.GC1500@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:43:57 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOaWNvbGFzIFdpbGxpYW1zIFtt YWlsdG86Tmljb2xhcy5XaWxsaWFtc0BzdW4uY29tXQ0KPiBTZW50OiBNb25kYXksIE1heSAwNCwg MjAwOSA5OjA3IEFNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogQnJhZCBGaXR6cGF0 cmljazsgU2FtIEpvaG5zdG9uOyBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IE9uIHRoZSBwcm9saWZlcmF0aW9uIG9mIHdlbGwta25vd24gVVJMczsgZHJhZnQtbm90dGluZ2hh bS0NCj4gc2l0ZS1tZXRhLTAxDQo+IA0KPiBPbiBNb24sIE1heSAwNCwgMjAwOSBhdCAwODoxODox N0FNIC0wNzAwLCBFcmFuIEhhbW1lci1MYWhhdiB3cm90ZToNCj4gPiBUaGlzIG1ha2VzIHNlbnNl IGJ1dCBJIGRvbuKAmXQgaGF2ZSBzdHJvbmcgdmlld3MgaGVyZS4gTXkgb25seSBjb25jZXJuDQo+ ID4gaXMgdG8gZ2V0IHRoaXMgYWRvcHRlZCBmb3IgaG9zdC1tZXRhIHNvIHdoYXRldmVyIHByb3Zl cyB0byBiZSB0aGUNCj4gcGF0aA0KPiA+IG9mIGxlYXN0IHJlc2lzdGFuY2Ugd29ya3MgZm9yIG1l Lg0KPiA+DQo+ID4gT24gdGhlIGJ1c2luZXNzIG9mIHVzaW5nIG9kZCBjaGFyYWN0ZXJzLCBpc27i gJl0IGNob29zaW5nIGFueSDigJgqL+KAmQ0KPiA+IHByZWZpeCBnb2luZyB0byBzb2x2ZSB5b3Vy IGNvbmNlcm5zPyBObyBzaXRlIEkga25vdyBhbGxvd3MgdXNpbmcg4oCYL+KAmQ0KPiA+IGZvciB1 c2VybmFtZXMsIHNob3J0IFVSTHMsIGV0Yy4gSeKAmW0gYWZyYWlkIG1ha2luZyB0aGUgcHJlZml4 IOKAnHVnbHnigJ0NCj4gPiB3aWxsIGNhdXNlIHBlb3BsZSBub3QgdG8gdXNlIGl0IGFuZCB3aWxs IG1ha2UgZG9jdW1lbnRpbmcgaXQNCj4gY29uZnVzaW5nDQo+ID4gdG8gcGVvcGxlIHdobyB3aWxs IG5vdCBiZSBleHBlY3Rpbmcgc29tZXRoaW5nIGxpa2UgdGhhdC4NCj4gDQo+IEJ1dCBzaXRlcyBk byBvZnRlbiBhbGxvdyB1c2VycyB0byBoYXZlIGZpbGVzLCBzbyAiKi8iIGZhbGxzIGRvd24uDQoN ClRoYXQgZ29lcyBiZXlvbmQgd2hhdCB3ZSBjYW4gcmVhc29uYWJsZSBwcm90ZWN0IGFnYWluc3Qu IElmIHlvdSBhcmUgZ29pbmcgdG8gbGV0IHVzZXJzIGRvIHdoYXRldmVyIHRoZXkgd2FudCBvbiB5 b3VyIHJvb3QgbmFtZXNwYWNlLCB5b3UgYXJlIGdvaW5nIHRvIGhhdmUgb3RoZXIgcHJvYmxlbXMu IFNpdGVzIGFsbG93aW5nIHVzZXJzIHRvIGhhdmUgZmlsZXMgdW5kZXIgY3VzdG9tIHN1Yi1kaXJl Y3RvcmllcyB3aWxsIG5lZWQgbW9yZSBwcm90ZWN0aW9ucyB0aGFuIGp1c3Qgc29tZSAqcG90ZW50 aWFsbHkqIGlsbGVnYWwgY2hhcmFjdGVycy4NCg0KRUhMDQo= From Lisa.Dusseault@messagingarchitects.com Mon May 4 09:58:51 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B7E3A6B28 for ; Mon, 4 May 2009 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJSZGvMvRqxC for ; Mon, 4 May 2009 09:58:50 -0700 (PDT) Received: from mplus1.messagingarchitects.com (bastille.messagingarchitects.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id C40CD3A6972 for ; Mon, 4 May 2009 09:58:49 -0700 (PDT) Received: from [192.168.1.104] lisad@messagingarchitects.com [74.95.2.169] by mplus1.messagingarchitects.com with M+ Extreme Email Engine 2008.4.release; Mon, 04 May 2009 13:00:26 -0400 X-MailFrom: Lisa.Dusseault@messagingarchitects.com Message-Id: <1022CDBE-418A-4AB7-AF7E-E93ED5161B5E@messagingarchitects.com> From: Lisa Dusseault To: Lisa Dusseault's Chairs , Apps Discuss Content-Type: multipart/alternative; boundary=Apple-Mail-339--991282853 Subject: Lisa's Apps Area Activity Report for Apr 2009 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 10:00:05 -0700 X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.release ; timestamp: Mon, 04 May 2009 13:00:27 -0400 engine: XCFAntiVirus1 Engine; version: 4052 (20090504)/1085 (20090428)/1091 (20090309)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5604 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A010205.49FF1F18.0229,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.release ; timestamp: Mon, 04 May 2009 13:00:28 -0400 engine: XCFSPAM3 Engine ; version: 5.07.0001 ; level: 1 ref: str=0001.0A010209.49FF1F19.01A6,ss=1,fgs=0 status: success ;error: none engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-8434-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.2.1/2009.05.02.02.55.58/2005.02.11.04.44.13/0/0/2009.04.13.23.00.00/2007.02.13.01.23.26/0/0/2009.04.29.21.48.22/2009.05.04.15.01.00/2009.05.04.01.40.00/2009.05.04.15.46.11/0/0/2009.04.28.19.50.44/; level: 10 ref: 3 100 status: success ;error: none X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:58:51 -0000 --Apple-Mail-339--991282853 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit News, Updates - OAUTH: Proposed charter saw no serious objections in IETF Last Call - HYBI: Active traffic on different models and requirements for reverse or bidi HTTP: https://www.ietf.org/mailman/listinfo/hybi Document Status and Progress Active documents, my action: - draft-ietf-calsify-2446bis (PS): Need to find out if it's really ready for IETF Last Call this time Active documents, waiting on other: - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected, then I need to determine next state - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt review Finished processing -- new in RFC Ed queue and new RFCs - draft-ietf-calsify-rfc2445bis (PS): Approved, announcement sent RFC5451: Message Header Field for Indicating Message Authentication Status Dead (or pining for the fjords): - draft-snell-atompub-bidi (PS): Waiting for a revision > 6 months - draft-wilde-sms-uri (PS): Waiting for a revision > 6 months WG Status ALTO: Various discussions about documents being accepted as WG docs. CALSIFY: Not much WG action but RFC2445bis approved HTTPBIS: Discussion on Content Sniffing (see draft-abarth-mime-sniff) and related changes to core HTTP requirements IDNABIS: Discussing what mapping or user assistance might be, along with various definitions of "valid" at different points SIEVE: SIEVE-in-XML and sieve-include discussions --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. --Apple-Mail-339--991282853 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
News, = Updates
 - OAUTH: Proposed charter saw no serious = objections in IETF Last Call
 - HYBI: Active traffic on = different models and requirements for reverse or bidi HTTP: https://www.ietf.org/m= ailman/listinfo/hybi

Document Status and = Progress
Active documents, my action:
 - = draft-ietf-calsify-2446bis (PS): Need to find out if it's really ready = for IETF Last Call this time

Active documents, = waiting on other:
 - draft-montemurro-gsma-imei-urn = (Exp): New version of draft expected, then I need to determine next = state
 - draft-reschke-webdav-post (Exp): = Cyrus Daboo is doing shepherd review and writeup
 - = draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt = review

Finished processing -- new in RFC Ed = queue and new RFCs
 - draft-ietf-calsify-rfc2445bis (PS): = Approved, announcement = sent 
 RFC5451: Message Header Field = for Indicating Message Authentication = Status

Dead (or pining for the = fjords):
 - draft-snell-atompub-bidi (PS): Waiting = for a revision > 6 months
 - draft-wilde-sms-uri (PS): = Waiting for a revision > 6 = months


WG = Status

ALTO: Various discussions about = documents being accepted as WG docs.
CALSIFY: Not much = WG action but RFC2445bis approved
HTTPBIS: Discussion on = Content Sniffing (see draft-abarth-mime-sniff) and related changes = to core HTTP requirements
IDNABIS:  Discussing what = mapping or user assistance might be, along with various definitions of = "valid" at different points
SIEVE:  SIEVE-in-XML and = sieve-include discussions 

= --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. --Apple-Mail-339--991282853-- From alexey.melnikov@isode.com Tue May 5 06:20:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93A73A67DA for ; Tue, 5 May 2009 06:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAiFDy6uplpt for ; Tue, 5 May 2009 06:20:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D697B3A6D32 for ; Tue, 5 May 2009 06:20:02 -0700 (PDT) Received: from [172.16.2.148] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 5 May 2009 14:21:27 +0100 Message-ID: <4A003D39.8020004@isode.com> Date: Tue, 05 May 2009 14:20:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss , alexey-melnikov-chairs@tools.ietf.org Subject: Alexey's Apps Area Activity Report for April 2009 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:20:04 -0000 Please let me know if you think the information below is not accurate. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document Status and Progress Active documents, my action: - draft-hollenbeck-rfc493*bis - Scott Hollenbeck has requested=20 progression of these documents to Full Standard. I've reviewed 2=20 documents, need to review the remaining - draft-ietf-webdav-bind (Experimental) - need to do AD review - draft-duerst-mailto-bis - promised Martin D=FCrst to review this document Active documents in IETF LC or IESG review: - draft-crocker-email-arch (Standard Track): in IETF LC - draft-ietf-lemonade-notifications (Informational): on IESG telechat=20 agenda for May 7th - draft-thomson-beep-async (Proposed Standard): on IESG telechat agenda=20 for May 7th - draft-ncook-urlauth-accessid (Proposed Standard): on IESG telechat=20 agenda for May 7th (Note: normative dependency for=20 draft-ietf-lemonade-streaming) Active documents, waiting on other: - draft-ietf-ltru-4646bis (BCP) - IETF LC ended, waiting for a new=20 revision addressing my comments raised in AD review (Note: still waiting=20 for some extra reviews from the Apps Review Team) - draft-ietf-ltru-4645bis (Informational): IETF LC ended, waiting for=20 update to draft-ietf-ltru-4646bis before sending both to IESG for review - draft-ietf-lemonade-streaming (Informational): 2 DISCUSSes remaining=20 on the document (from Pasi and Cullen). Pasi has suggested some text,=20 I've suggested the author to revise the document to incorporate it. List of DISCUSSes I am currently holding: Old: draft-ietf-bfd-base-09.txt draft-ietf-avt-rtp-speex-06.txt draft-ietf-ipfix-exporting-type-03.txt draft-ietf-ntp-ntpv4-proto-11.txt draft-ietf-ipfix-file-03.txt draft-ietf-nsis-ntlp-19.txt draft-mraihi-inch-thraud-08.txt New (this week): draft-ietf-isms-tmsm-17.txt draft-ietf-isms-secshell-16.txt draft-ietf-openpgp-camellia-04.txt Other activities/actions: Done: - Took over the DISCUSS entered by Chris Newman for the iCalendar spec.=20 An RFC Editor note was entered to address it, so I cleared - YAM (Yet Another Mail) WG charter proposal for IESG review on May 7th Ongoing: - Request to review 3 new MIME type registrations: - Request for registration for 3gpp-ims+xml: ongoing private=20 discussion with authors of the registration - Request for registration for application/mp21 from ISO/IEC=20 21000-9:2005/Amd.1:2008: need to followup - Request for registration for multiple MIME types=20 () from Library=20 of Congress: need to advise on the best way forward with this.=20 - Discussion about FTP ALG for IPv6-to-IPv4 translation=20 (draft-van-beijnum-behave-ftp64) My action: - Need to review OAuth document regarding possible reuse of SCRAM Waiting for others: - Request to move SMTP AUTH (RFC 4954) to Draft Standard (waiting for=20 Lisa's response) - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update=20 the document, Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate=20 draft (Ned Freed agreed to do this) - Suggestion to write a document documenting use of DNS SRV records for=20 discovering location of SMTP/IMAP/POP and calendaring servers (Cyrus=20 Daboo agreed to work on this) WG Status: EAI - waiting for the WG to finish POP3 and IMAP drafts. No activity on=20 the mailing list Lemonade - RFC 5524 got published. Pushing dependencies for the Lemonade=20 Profile Bis out of the door (draft-newman-auth-scram-12.txt, QRESYNC=20 (draft-ietf-lemonade-5162bis-00.txt)). Also a couple of informational=20 documents in IESG review LTRU - IETF LC for both outstanding documents have finished, waiting for=20 the WG to produce updated drafts MORG - No activity in the last 2 weeks VCARDDAV - Discussion about the best way of encoding vCard parameters in XML From mnot@mnot.net Wed May 6 03:14:58 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD183A6C88 for ; Wed, 6 May 2009 03:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=-2.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cUXfr4WB42q for ; Wed, 6 May 2009 03:14:51 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 7756A3A6E50 for ; Wed, 6 May 2009 03:14:34 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.158.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2DEB323E3E8; Wed, 6 May 2009 06:15:53 -0400 (EDT) Message-Id: <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> From: Mark Nottingham To: Brad Fitzpatrick , apps-discuss@ietf.org In-Reply-To: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Date: Wed, 6 May 2009 20:15:51 +1000 References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:14:58 -0000 I don't buy this argument, because twitter et al have clearly worked =20 around robots.txt, favicon.ico and many others without any apparent =20 problem. If you run a Web site that allows users to create arbitrary =20 URLs, it's your responsibility to anticipate this, and I'd note that =20 this seems to be working just fine with the non-standard locations =20 above; why wouldn't they work with a standard one? That said, if people think it's necessary to address this, I can see =20 two possibilities (adding semicolons and other such line noise to the =20= path is ugly and brings its own problems, as pointed out): 1) using ".host-meta" -- dot-files are a widely-recognise convention, =20= and are relatively friendly to implementations, or 2) using /host-meta/* or for that matter, /well-known/* -- i.e., =20 setting aside a path component whose children are registered path =20 components, one per application, instead of having a single =20 "directory" file. This increases the "footprint" of the solution in =20 terms of URI namespace impingment, but reduces the number of requests =20= (often). Thoughts? Cheers, On 30/04/2009, at 3:50 AM, Brad Fitzpatrick wrote: > I'd like to discuss the proliferation of well-known URLs, notably =20 > the new one proposed in draft-nottingham-site-meta-01. > > I talked to Eran Hammer-Lahav about this, but he suggested I bring =20 > it up here: > > I object to the use of /host-meta for two reasons: > > 1) I feel that /host-meta is too casual of a name and prone to =20 > collisions. It matches /^[\w\-]+$/, which I think is a subset of a =20= > fair number of sites' usernames. > > 2) There are already too many well-known URLs cluttering up the =20 > namespace: > > /robots.txt > /favicon.ico > /crossdomain.xml > > We can't fix those, but rather than make another one (and don't kid =20= > yourself: /host-meta won't be the last one) and make the situation =20 > worse, I propose we do the respectful thing and make a well-known =20 > directory to put this and all future well-known files in. e.g.: > > /;well_known/host-meta > > i.e. put something ugly and weird in there, like a semicolon, to =20 > minimize the chance that it interferes with people's existing URL =20 > structure. > > Hopefully when the next spec decides to add a new well-known URL, =20 > they put it under /;well_known/. "But host-meta is the final one, =20 > forever!", you say. I doubt it. XRD will become pass=E9, or people =20= > will object to doing two HTTP requests when they really want to do =20 > one, so yet another well-known URL will be born. Let's give it a =20 > future home now. > > Thoughts? > > - Brad > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From samj@samj.net Wed May 6 03:33:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7793A680A for ; Wed, 6 May 2009 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUNawdTgR8x8 for ; Wed, 6 May 2009 03:33:18 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id E2FED3A686A for ; Wed, 6 May 2009 03:33:17 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so3695ana.4 for ; Wed, 06 May 2009 03:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.19.65 with SMTP id z1mr670015iba.53.1241606082897; Wed, 06 May 2009 03:34:42 -0700 (PDT) In-Reply-To: <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> Date: Wed, 6 May 2009 12:34:42 +0200 Message-ID: <21606dcf0905060334u7b12cf55i1e3ba19124fd9678@mail.gmail.com> Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Sam Johnston To: Mark Nottingham Content-Type: multipart/alternative; boundary=00221532cb4885aa4704693bf168 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 10:33:18 -0000 --00221532cb4885aa4704693bf168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, May 6, 2009 at 12:15 PM, Mark Nottingham wrote: > 1) using ".host-meta" -- dot-files are a widely-recognise convention, and > are relatively friendly to implementations, or > > 2) using /host-meta/* or for that matter, /well-known/* -- i.e., setting > aside a path component whose children are registered path components, one > per application, instead of having a single "directory" file. This increases > the "footprint" of the solution in terms of URI namespace impingment, but > reduces the number of requests (often). > > Thoughts? > The second option sounds better than the first which sounds better in turn than the ugly URLs (which are sure to trip application firewalls, proxies, filters, etc. all over the shop). For host-meta (and meta-data for that matter, which could be an even better option) we're not standing on any toes - according to Google at least. I would suggest mentioning that users should not be able to create content under this hierarchy as a security consideration. It may also be worth looking at how existing root pollution might be migrated over time. Sam --00221532cb4885aa4704693bf168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 6, 2009 at 12:15 PM, Mark Nottingham <mnot@mnot.net> wrote:
1) using ".host-meta" -- dot-fil= es are a widely-recognise convention, and are relatively friendly to implem= entations, or

2) using /host-meta/* or for that matter, /well-known/* -- i.e., setting as= ide a path component whose children are registered path components, one per= application, instead of having a single "directory" file. This i= ncreases the "footprint" of the solution in terms of URI namespac= e impingment, but reduces the number of requests (often).

Thoughts?

The second option sounds better than = the first which sounds better in turn than the ugly URLs (which are sure to= trip application firewalls, proxies, filters, etc. all over the shop).
For host= -meta (and meta-data for that matter, which could be an even better option) we= 9;re not standing on any toes - according to Google at least.

I would suggest mentioning that users should not be able to create cont= ent under this hierarchy as a security consideration. It may also be worth = looking at how existing root pollution might be migrated over time.

Sam

--00221532cb4885aa4704693bf168-- From alexey.melnikov@isode.com Wed May 6 04:52:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BC63A68C2 for ; Wed, 6 May 2009 04:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvPVV7a+3g5i for ; Wed, 6 May 2009 04:52:09 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 901803A6CFE for ; Wed, 6 May 2009 04:52:03 -0700 (PDT) Received: from [172.16.2.193] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 6 May 2009 12:53:29 +0100 Message-ID: <4A017A2C.9040902@isode.com> Date: Wed, 06 May 2009 12:53:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss Subject: Re: Alexey's Apps Area Activity Report for April 2009 References: <4A003D39.8020004@isode.com> In-Reply-To: <4A003D39.8020004@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:52:10 -0000 Alexey Melnikov wrote: > Waiting for others: > - Request to move SMTP AUTH (RFC 4954) to Draft Standard (waiting for > Lisa's response) > - Suggestion to move LMTP to Standard Track (Ned Freed agreed to > update the document, Chris Newman agreed to shepherd it) > - Suggestion to convert MIME BNF to ABNF and publish as a separate > draft (Ned Freed agreed to do this) > - Suggestion to write a document documenting use of DNS SRV records > for discovering location of SMTP/IMAP/POP and calendaring servers > (Cyrus Daboo agreed to work on this) Other things I forgot to mention: - Support for UTF-8 in LDIF discussion (Kurt Zeilenga and I are tracking this) - TLS server certificate verification procedure for Apps protocols - there was lots of support for having this document, but the current authors didn't respond. Kurt Zeilenga has volunteered to edit, if the original authors don't have time. If I don't hear any objections soon (say before the end of May), then I would ask Kurt to edit this document. If anybody else wants to co-edit, let me know. From eran@hueniverse.com Wed May 6 09:54:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5749A3A6BB0 for ; Wed, 6 May 2009 09:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck2XNYR3C6DE for ; Wed, 6 May 2009 09:53:59 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3BEAF3A69BA for ; Wed, 6 May 2009 09:51:58 -0700 (PDT) Received: (qmail 30147 invoked from network); 6 May 2009 16:53:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 May 2009 16:53:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 6 May 2009 09:53:14 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , Brad Fitzpatrick , "apps-discuss@ietf.org" Date: Wed, 6 May 2009 09:53:09 -0700 Subject: RE: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Thread-Topic: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 Thread-Index: AcnOM7iaqyKGkIYsT1WNL7G9wcKNugANI7pg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343780B0020A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> In-Reply-To: <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:54:06 -0000 I would like to keep the single-file we have proposed. The main use cases f= or host-meta today are mostly focused on using Link-Pattern records more th= an Link records. I also want to preserve the ability to place these files e= lsewhere (on a different path or host) which is easier to do with a Link re= cord than a 3xx in most deployments. So the question is where to put it and what to name it. I like the idea of a directory. So we either find a new name for the directory (I don't like /well-known/*)= , or use /host-meta/* and find a new name for the file (such as directory, = index, global, etc.). EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Wednesday, May 06, 2009 3:16 AM > To: Brad Fitzpatrick; apps-discuss@ietf.org > Subject: Re: On the proliferation of well-known URLs; draft-nottingham- > site-meta-01 >=20 > I don't buy this argument, because twitter et al have clearly worked > around robots.txt, favicon.ico and many others without any apparent > problem. If you run a Web site that allows users to create arbitrary > URLs, it's your responsibility to anticipate this, and I'd note that > this seems to be working just fine with the non-standard locations > above; why wouldn't they work with a standard one? >=20 > That said, if people think it's necessary to address this, I can see > two possibilities (adding semicolons and other such line noise to the > path is ugly and brings its own problems, as pointed out): >=20 > 1) using ".host-meta" -- dot-files are a widely-recognise convention, > and are relatively friendly to implementations, or >=20 > 2) using /host-meta/* or for that matter, /well-known/* -- i.e., > setting aside a path component whose children are registered path > components, one per application, instead of having a single > "directory" file. This increases the "footprint" of the solution in > terms of URI namespace impingment, but reduces the number of requests > (often). >=20 > Thoughts? >=20 > Cheers, >=20 >=20 > On 30/04/2009, at 3:50 AM, Brad Fitzpatrick wrote: >=20 > > I'd like to discuss the proliferation of well-known URLs, notably > > the new one proposed in draft-nottingham-site-meta-01. > > > > I talked to Eran Hammer-Lahav about this, but he suggested I bring > > it up here: > > > > I object to the use of /host-meta for two reasons: > > > > 1) I feel that /host-meta is too casual of a name and prone to > > collisions. It matches /^[\w\-]+$/, which I think is a subset of a > > fair number of sites' usernames. > > > > 2) There are already too many well-known URLs cluttering up the > > namespace: > > > > /robots.txt > > /favicon.ico > > /crossdomain.xml > > > > We can't fix those, but rather than make another one (and don't kid > > yourself: /host-meta won't be the last one) and make the situation > > worse, I propose we do the respectful thing and make a well-known > > directory to put this and all future well-known files in. e.g.: > > > > /;well_known/host-meta > > > > i.e. put something ugly and weird in there, like a semicolon, to > > minimize the chance that it interferes with people's existing URL > > structure. > > > > Hopefully when the next spec decides to add a new well-known URL, > > they put it under /;well_known/. "But host-meta is the final one, > > forever!", you say. I doubt it. XRD will become pass=E9, or people > > will object to doing two HTTP requests when they really want to do > > one, so yet another well-known URL will be born. Let's give it a > > future home now. > > > > Thoughts? > > > > - Brad > > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From brad@fitzpat.com Wed May 6 10:58:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14F63A70D3 for ; Wed, 6 May 2009 10:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xozkVjMd+v3k for ; Wed, 6 May 2009 10:58:56 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id C70153A6F91 for ; Wed, 6 May 2009 10:53:13 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so225076ywj.49 for ; Wed, 06 May 2009 10:54:38 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.100.12.17 with SMTP id 17mr1817581anl.2.1241632478437; Wed, 06 May 2009 10:54:38 -0700 (PDT) In-Reply-To: <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> Date: Wed, 6 May 2009 10:54:38 -0700 X-Google-Sender-Auth: 4a67510a7b770cf5 Message-ID: <1076e6c00905061054y4e152043ld723966947716156@mail.gmail.com> Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Brad Fitzpatrick To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e644ddfcd1a364046942165c Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 17:58:57 -0000 --0016e644ddfcd1a364046942165c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Wed, May 6, 2009 at 3:15 AM, Mark Nottingham wrote: > I don't buy this argument, because twitter et al have clearly worked around > robots.txt, favicon.ico and many others without any apparent problem. Because those two have been around for ages. We can't just keep adding more, though. You can't anticipate all the future crap people are going to add. > If you run a Web site that allows users to create arbitrary URLs, it's your > responsibility to anticipate this, and I'd note that this seems to be > working just fine with the non-standard locations above; why wouldn't they > work with a standard one? With future standards they don't know about yet? > That said, if people think it's necessary to address this, I can see two > possibilities (adding semicolons and other such line noise to the path is > ugly and brings its own problems, as pointed out): > > 1) using ".host-meta" -- dot-files are a widely-recognise convention, and > are relatively friendly to implementations, or > > 2) using /host-meta/* or for that matter, /well-known/* -- i.e., setting > aside a path component whose children are registered path components, one > per application, instead of having a single "directory" file. This increases > the "footprint" of the solution in terms of URI namespace impingment, but > reduces the number of requests (often). > > Thoughts? I'd be happy with either: /.wellknown/host-meta /,wellknown/host-meta A comma is weird enough that it's not likely to be in potential use, but nice enough to be acceptable in filesystem components (for those actually storing this stuff on filesystem) and isn't a shell special character for people fetching these URLs with curl, etc. But the dotfile directory is more 'normal' and I could see people being more accepting of it. I like it because no site should be insane enough to let people's usernames start with periods. On the other hand, http://profiles.google.com/.wellknown/ ... could become valid, if the existing user wellknown@gmail.com creates a public profile. (periods anywhere in gmail usernames are ignored) But I'm not worried about the google profile case. /.wellknown/ is still good. - Brad --0016e644ddfcd1a364046942165c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 6, 2009 at 3:15 AM, Mark Nottingham = <mnot@mnot.net>= ; wrote:
If yo= u run a Web site that allows users to create arbitrary URLs, it's your = responsibility to anticipate this, and I'd note that this seems to be w= orking just fine with the non-standard locations above; why wouldn't th= ey work with a standard one?

With future standards they don't know about yet?
=C2=A0
That said, if people think it's necessary to address this, I can see tw= o possibilities (adding semicolons and other such line noise to the path is= ugly and brings its own problems, as pointed out):

1) using ".host-meta" -- dot-files are a widely-recognise convent= ion, and are relatively friendly to implementations, or

2) using /host-meta/* or for that matter, /well-known/* -- i.e., setting as= ide a path component whose children are registered path components, one per= application, instead of having a single "directory" file. This i= ncreases the "footprint" of the solution in terms of URI namespac= e impingment, but reduces the number of requests (often).

Thoughts?

I'd be happy with either:

/.wellknown/host-meta
/,wellknown/host-meta

A comma is weird enough that it's not likely to be in potential use, but nice enough to be acceptable in filesystem components (for those actually storing this stuff on filesystem) and isn't a shell special character for people fetching these URLs with curl, etc.

But the dot= file directory is more 'normal' and I could see people being more a= ccepting of it.=C2=A0 I like it because no site should be insane enough to = let people's usernames start with periods.=C2=A0 On the other hand,

http://profiles.goog= le.com/.wellknown/

... could become valid, if the existing user = wellknown@gmail.com creates a pu= blic profile.=C2=A0 (periods anywhere in gmail usernames are ignored)

But I'm not worried about the google profile case.=C2=A0 /.wellknow= n/ is still good.

- Brad
--0016e644ddfcd1a364046942165c-- From brad@fitzpat.com Wed May 6 16:12:18 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D873A6B46 for ; Wed, 6 May 2009 16:12:18 -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.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RNlg+Bz0+QT for ; Wed, 6 May 2009 16:12:17 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 4FFC93A68AB for ; Wed, 6 May 2009 16:12:16 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so402938yxb.49 for ; Wed, 06 May 2009 16:13:42 -0700 (PDT) MIME-Version: 1.0 Sender: brad@fitzpat.com Received: by 10.100.166.10 with SMTP id o10mr3721763ane.126.1241651622261; Wed, 06 May 2009 16:13:42 -0700 (PDT) In-Reply-To: <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> References: <1076e6c00904291050t6dcde913seedb6c8e06d1a090@mail.gmail.com> <49872827-DF58-441A-9E8F-3310D6D3E710@mnot.net> Date: Wed, 6 May 2009 16:13:41 -0700 X-Google-Sender-Auth: faaac8a63614cf08 Message-ID: <1076e6c00905061613s4503246l1b434e96ea7e38fd@mail.gmail.com> Subject: Re: On the proliferation of well-known URLs; draft-nottingham-site-meta-01 From: Brad Fitzpatrick To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016e6434aeae13f3a0469468be6 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 23:12:18 -0000 --0016e6434aeae13f3a0469468be6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Wed, May 6, 2009 at 3:15 AM, Mark Nottingham wrote: > I don't buy this argument, because twitter et al have clearly worked around > robots.txt, favicon.ico and many others without any apparent problem. Counter-point: http://profiles.google.com/robots.txt http://profiles.google.com/favicon.ico I'll file a bug, but that just goes to show that people DO have problems with this. (For the record: it redirects to the user's canonical profile URL....) Apparently robotstxt at gmail.com exists (I tried to create the account and it said taken), which Google properties treat identically to "robots.txt" (periods aren't signifigant) so that URL above is for a Google user that doesn't have a public profile or has a public profile with a obfuscated numeric URL. Please, no more top-level URLs. Let's minimize special-casing in future/current web apps. --0016e6434aeae13f3a0469468be6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 6, 2009 at 3:15 AM, Mark Nottingham = <mnot@mnot.net>= ; wrote:
http://profiles.google.com/robots.txt
http://profiles.google.c= om/favicon.ico

I'll file a bug, but that just goes to show t= hat people DO have problems with this.

(For the record:=C2=A0 it red= irects to the user's canonical profile URL....)

Apparently robotstxt at gmail.com exis= ts (I tried to create the account and it said taken), which Google properti= es treat identically to "robots.txt" (periods aren't signifig= ant) so that URL above is for a Google user that doesn't have a public = profile or has a public profile with a obfuscated numeric URL.

Please, no more top-level URLs.=C2=A0 Let's minimize special-casing= in future/current web apps.
--0016e6434aeae13f3a0469468be6-- From ht@inf.ed.ac.uk Mon May 4 09:51:12 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8449C3A6358 for ; Mon, 4 May 2009 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9H7IC377hpx for ; Mon, 4 May 2009 09:51:11 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by core3.amsl.com (Postfix) with ESMTP id 1284A28C0E1 for ; Mon, 4 May 2009 09:51:02 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id n44GqEip017549; Mon, 4 May 2009 17:52:14 +0100 (BST) Received: from hildegard.inf.ed.ac.uk (hildegard.inf.ed.ac.uk [129.215.24.147]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id n44GqC08005678; Mon, 4 May 2009 17:52:13 +0100 Received: from hildegard.inf.ed.ac.uk (localhost [127.0.0.1]) by hildegard.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id n44GqCgO003118; Mon, 4 May 2009 17:52:12 +0100 Received: (from ht@localhost) by hildegard.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id n44Gq9X0003117; Mon, 4 May 2009 17:52:09 +0100 X-Authentication-Warning: hildegard.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: =?iso-2022-int-1?B?TWFydGluIEouIET8cnN0?= Subject: Re: A new RFC for Web Addresses/Hypertext References: Background wrt LEIRIs ( ISSUE-27 ) References: <49FAA279.4070008@it.aoyama.ac.jp> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 04 May 2009 17:52:09 +0100 In-Reply-To: <49FAA279.4070008@it.aoyama.ac.jp> (Martin J. =?iso-2022-int-1?B?RPxyc3Qncw==?= message of "Fri, 01 May 2009 16:19:21 +0900") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 X-Mailman-Approved-At: Wed, 06 May 2009 20:26:21 -0700 Cc: public-iri@w3.org, Lisa Dusseault , www-tag@w3.org, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 17:06:17 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henry S. Thompson wrote: > Once it became apparent, however, that the progress of [IRI-BIS] to > Draft Standard status was likely to be considerably delayed for > reasons outside its editors' control Two questions have arisen wrt this: 1) Why "Draft Standard"? My mistake -- I misunderstood the IETF nomenclature -- all we need is for [IRI-BIS] to be published as an RFC with an RFC number. 2) What "reasons outside its editors' control"? I don't trust my memory of the relevant rumours sufficiently to commit it to print: Martin, would you care to hazard a guess as to when [IRI-BIS] might be published as an RFC, and/or tell us what the hold-up was or is? ht =2D --=20 Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged sp= am] =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFJ/x05kjnJixAXWBoRAqONAJ9ZgBE+0gekeIITtx4HFgeLz4QdcACbBci8 C4ky5KpXgSTsQVgzVNhPwJ4=3D =3DlQAe =2D----END PGP SIGNATURE----- From masinter@adobe.com Mon May 4 11:53:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1CE3A6DA0 for ; Mon, 4 May 2009 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mAHEqWqwyLR for ; Mon, 4 May 2009 11:53:29 -0700 (PDT) Received: from chip2og50.obsmtp.com (chip2og50.obsmtp.com [64.18.13.37]) by core3.amsl.com (Postfix) with ESMTP id 4121E3A6FED for ; Mon, 4 May 2009 11:53:27 -0700 (PDT) Received: from source ([192.150.11.134]) by chip2ob50.postini.com ([64.18.5.12]) with SMTP ID DSNKSf85ztGQei+DFcOatcJGapHDi4e+H6a3@postini.com; Mon, 04 May 2009 11:54:55 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n44ImDeM004651; Mon, 4 May 2009 11:48:13 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n44Is3iq013163; Mon, 4 May 2009 11:54:03 -0700 (PDT) Received: from nambx04.corp.adobe.com ([10.8.127.98]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 4 May 2009 11:54:02 -0700 From: Larry Masinter To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Dan Connolly Date: Mon, 4 May 2009 11:54:02 -0700 Subject: RE: A new RFC for Web Addresses/Hypertext References: Background wrt LEIRIs Thread-Topic: A new RFC for Web Addresses/Hypertext References: Background wrt LEIRIs Thread-Index: AcnKPhB6uvfrDWVKQKqK8tOULU6ligCp1btA Message-ID: <8B62A039C620904E92F1233570534C9B0118CD741300@nambx04.corp.adobe.com> References: <1241109226.8402.1139.camel@pav.lan> <49FABE79.9090307@it.aoyama.ac.jp> In-Reply-To: <49FABE79.9090307@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 May 2009 20:26:48 -0700 Cc: "Henry S. Thompson" , Apps Discuss , "public-iri@w3.org" , "www-tag@w3.org" , Lisa Dusseault X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:53:31 -0000 RXZlbiBpZiB0aGVyZSBhcmUgZGlmZmVyZW50IHJlcXVpcmVtZW50cyBmb3IgZGlmZmVyZW50IHBy b3RvY29sIGVsZW1lbnRzLA0KSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gaGF2ZSBhIHNpbmds ZSBkb2N1bWVudCB3aGljaCBkZXNjcmliZXMgYWxsDQpvZiB0aGUgVVJJLWxpa2UgcHJvdG9jb2wg ZWxlbWVudHMgdGhhdCBhcmUgdXNlZCBvbiB0aGUgd2ViLCBldmVuIGlmDQppdCBtZWFucyB0aGF0 IE9ORSBkb2N1bWVudCBkZWZpbmVzIFRIUkVFIGRpZmZlcmVudCBwcm90b2NvbCBlbGVtZW50cy4N Cg0KV2hhdCBpcyB1bmFjY2VwdGFibGUgaXMgdG8gaGF2ZSBmb3VyIGRpZmZlcmVudCBkb2N1bWVu dHMgd2l0aCBubyBjbGVhcg0KZGVsaW5lYXRpb24gYmV0d2VlbiB0aGVtLg0KDQpJdCdzIHF1aXRl IHBvc3NpYmxlIHRoYXQgc29tZSBvZiB0aGUgZGlzY3Vzc2lvbiBjdXJyZW50bHkgDQp0YXJnZXRl ZCBhdCBnZW5lcmljIFVSSXMgYW5kIElSSXMgYW5kIExFSVJJcyBhbmQgV2ViIEFkZHJlc3NlcyAN CnNob3VsZCBpbnN0ZWFkIGJlIG1vdmVkIGludG8gdGhlIGRvY3VtZW50cyBmb3IgaHR0cDosIGZ0 cDosIA0KYW5kIGZpbGU6IFVSSXMsIGFuZCBzb21lIGludG8gYSBzZXBhcmF0ZSBkb2N1bWVudCB3 aGljaCBkZXNjcmliZXMNCnRoZSBwcm9jZXNzaW5nIG1vZGVsIGJ5IHdoaWNoIGEgZm9ybSwgZm9y bS1kYXRhIGNvcnJlc3BvbmRpbmcNCnRvIHRoZSBmb3JtLCBhbmQgYSBzdWJtaXQgVVJJIGFuZCBt ZXRob2QgY2FuIGJlIHR1cm5lZCBpbnRvDQphIFVSSSAoaWYgdGhlIG1ldGhvZCBpcyBHRVQpLCBl dGMuDQoNCkxhcnJ5DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHd3dy10 YWctcmVxdWVzdEB3My5vcmcgW21haWx0bzp3d3ctdGFnLXJlcXVlc3RAdzMub3JnXSBPbiBCZWhh bGYgT2YgIk1hcnRpbiBKLiBEw7xyc3QiDQpTZW50OiBGcmlkYXksIE1heSAwMSwgMjAwOSAyOjE5 IEFNDQpUbzogRGFuIENvbm5vbGx5DQpDYzogSGVucnkgUy4gVGhvbXBzb247IHd3dy10YWdAdzMu b3JnOyBwdWJsaWMtaXJpQHczLm9yZzsgQXBwcyBEaXNjdXNzOyBMaXNhIER1c3NlYXVsdDsgQWxl eGV5IE1lbG5pa292DQpTdWJqZWN0OiBSZTogQSBuZXcgUkZDIGZvciBXZWIgQWRkcmVzc2VzL0h5 cGVydGV4dCBSZWZlcmVuY2VzOiBCYWNrZ3JvdW5kIHdydCBMRUlSSXMNCg0KSGVsbG8gRGFuLA0K DQpbc2FtZSBhZGRlZCBjcm9zcy1wb3N0aW5ncyBhcyBmb3IgcHJldmlvdXMgbWFpbC5dDQoNCk9u IDIwMDkvMDUvMDEgMTozMywgRGFuIENvbm5vbGx5IHdyb3RlOg0KPiBPbiBUdWUsIDIwMDktMDQt MjggYXQgMTY6MzEgKzAxMDAsIEhlbnJ5IFMuIFRob21wc29uIHdyb3RlOg0KPiBbLi4uXQ0KPj4g ICBbV0VCQUREUl0gQSBwcmVsaW1pbmFyeSBkcmFmdCBvZiBhIHBvc3NpYmxlIFJGQyBmb3IgV2Vi IEFkZHJlc3Nlcw0KPj4gICAgICAgICAgICAgKGV4dHJhY3RlZCBmcm9tIEhUTUw1IFsxXSk6DQo+ PiAgICAgaHR0cDovL3d3dy53My5vcmcvaHRtbC93Zy9ocmVmL2RyYWZ0Lmh0bWwgW25vdCB5ZXQg aW4gUkZDIGZvcm1hdCwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29udmVydGVkIHZlcnNpb24gZXhwZWN0ZWQNCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUlNOXQ0KPiBbLi4uXQ0KPj4gSSBhbSBzdXJl IHRoYXQgdGhlIGFib3ZlIHN1bW1hcmllcyBjYW4gYmUgaW1wcm92ZWQuICBJbiBwYXJ0aWN1bGFy IGl0DQo+PiB3b3VsZCBiZSBoZWxwZnVsIGhhdmUgY2xlYXIgc3RhdGVtZW50cyBmcm9tIHRoZWly IHJlc3BlY3RpdmUNCj4+IGF1dGhvcnMvb3duZXJzIGFzIHRvIHdoYXQgdGhlIF9yZXF1aXJlbWVu dHNfIGZvciB0aGUgdGhyZWUgbmV3DQo+PiBkb2N1bWVudHMgKFtJUkktQklTXSwgW0xFSVJJXSBh bmQgW1dFQkFERFJdKSBhcmUuICBPbmx5IGFmdGVyIHdlIGhhdmUNCj4+IHRob3NlIHdvdWxkIGl0 IG1ha2Ugc2Vuc2UgdG8gdHVybiB0byB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB3ZSBjYW4NCj4+ IG1lcmdlIHNvbWUgb3IgYWxsIG9mIHRoZW0uDQo+DQo+IEdvb2QgcXVlc3Rpb24uIEkgaGFkIGhv cGVkIHRvIGRvY3VtZW50IHRoaXMgaW4gdGhlIGRyYWZ0IGJ5DQo+IG5vdy4NCj4NCj4gT25lIG9m IHRoZSBtYWluIHJlcXVpcmVtZW50cyB0aGUgZGVzaWduIGluIFtXRUJBRERSXSB0YWtlcw0KPiBv biBpcyB0aGUgbm9uLXdlc3Rlcm4gc2VhcmNoIGVuZ2luZSBwcm9ibGVtLg0KPg0KPiBNeSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgTVMgSUUgaW1wbGVtZW50ZWQgYSBwcmUtSVJJLA0KPiBwcmUtdW5p Y29kZSBjb252ZW50aW9uIHRoYXQgZm9ybSBzdWJtaXNzaW9uIGRhdGEgc2hvdWxkDQo+IGdvIGlu IHRoZSBlbmNvZGluZyB0aGF0IHRoZSBmb3JtIHBhZ2Ugd2FzIGVuY29kZWQgaW4sDQo+IGFuZCB0 aGUgc2VydmVycyBib3VnaHQgaW50byB0aGlzLg0KDQpJJ20gbm90IHN1cmUgdGhpcyB3YXMgSUUs IG9yIE5ldHNjYXBlLiBJdCB3YXMgZGVmaW5pdGVseSB2ZXJ5IGVhcmx5IGluIA0KdGhlIGdhbWUu IEl0IG1heSBhbHJlYWR5IGhhdmUgYmVlbiBpbiBzb21lIG9mIHRoZSB2ZXJ5IGVhcmx5IGxvY2Fs aXplZCANCmJyb3dzZXJzLiBPciB3ZSBtYXkgc2ltcGx5IHNlZSBpdCBhcyBhIGNvbnNlcXVlbmNl IG9mIHRoZSBmYWN0IHRoYXQgDQplYXJseSBicm93c2VycyBkaWRuJ3QgZG8gYSBjb252ZXJzaW9u IHRvIFVuaWNvZGUsIGJ1dCBrZXB0IGRhdGEgaW4gdGhlIA0KaW5jb21pbmcgZW5jb2RpbmcgaW50 ZXJuYWxseS4NCg0KRm9yIHNlcnZlcnMsIGl0IHdhcyBhbHNvIGVhc3kgdG8gYWRhcHQuIE9uIHRo ZSBhc3N1bXB0aW9uIHRoYXQgbW9zdCANCmZvcm1zIGFyZSBzZW50IGZyb20gcGFnZXMgZG93bmxv YWRlZCBmcm9tIHRoZSBzYW1lIHNlcnZlciwgaXQncyBlYXN5IHRvIA0KZ3Vlc3MgdGhhdCBhIHNl cnZlciB3b3JraW5nIGUuZy4gd2l0aCBFVUMtSlAgd291bGQgc2VuZCBpdHMgZG9jdW1lbnRzIA0K b3V0IGluIEVVQy1KUCBhbmQgd291bGQgcHJlZmVyIGdldHRpbmcgaXRzIGZvcm0gZGF0YSBiYWNr IGluIEVVQy1KUC4NClNvIGV2ZXJ5dGhpbmcgd29ya2VkIG91dCByZWxhdGl2ZWx5IGVhc2lseS4N Cg0KSFRNTDQgYWN0dWFsbHkgc2FuY3Rpb25zIHRoaXMgYmVoYXZpb3IsIGFzIGZvbGxvd3MgKHNl ZSANCmh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0MDEvaW50ZXJhY3QvZm9ybXMuaHRtbCNhZGVm LWFjY2VwdC1jaGFyc2V0KToNCiA+Pj4+DQpUaGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhpcyBhdHRy aWJ1dGUgaXMgdGhlIHJlc2VydmVkIHN0cmluZyAiVU5LTk9XTiIuIA0KVXNlciBhZ2VudHMgbWF5 IGludGVycHJldCB0aGlzIHZhbHVlIGFzIHRoZSBjaGFyYWN0ZXIgZW5jb2RpbmcgdGhhdCB3YXMg DQp1c2VkIHRvIHRyYW5zbWl0IHRoZSBkb2N1bWVudCBjb250YWluaW5nIHRoaXMgRk9STSBlbGVt ZW50Lg0KID4+Pj4NCg0KW2J0dywgSSBoYXZlIG5vIGlkZWEgd2hhdCBIVE1MNSBkb2VzIChvciBk b2Vzbid0KSBkbyB3aXRoIA0KYWNjZXB0LWNoYXJzZXQuIEZvciBhIGxvbmcgdGltZSwgSSB0aG91 Z2h0IGl0IHdhcyBkZWFkLCBidXQgdGhlbiBhIGZldyANCnllYXJzIGFnbywgc29tZWJvZHkgdG9s ZCBtZSB0aGF0IE1vemlsbGEgaGFkIGltcGxlbWVudGVkIGl0IGFzIHBhcnQgb2YgDQp0aGVpciBk cml2ZSB0byBiZWNvbWUgbW9yZSBzdGFuZGFyZHMtY29tcGxpYW50Ll0NCg0KDQo+IE1vemlsbGEg dHJpZWQgdG8gZm9sbG93IHRoZSBJUkkgc3BlYywgYnV0DQo+ICJUaGlzIGJyZWFrcyBtb3N0IHN1 Yi1jYXRlZ29yeSBsaW5rcyBvbiBhIGJpZyBncmVlayBvbi1saW5lIHBjJiAgZ2FkZ2V0DQo+IHNo b3ANCj4gKGh0dHA6Ly93d3cuZS1zaG9wLmdyKSByZW5kZXJpbmcgdGhlIHNpdGUgdW51c2FibGUu Ig0KPiBodHRwczovL2J1Z3ppbGxhLm1vemlsbGEub3JnL3Nob3dfYnVnLmNnaT9pZD0yODQ0NzQN Cg0KVW5mb3J0dW5hdGVseSwgdGhlIHRlc3QgcGFnZSBtZW50aW9uZWQgaW4gdGhhdCBidWcgcmVw b3J0IGlzIG5vIGxvbmdlciANCmF2YWlsYWJsZS4gSXQgc2VlbXMgdGhlIGRvbWFpbiBleHBpcmVk Lg0KDQpUaGUgaXNzdWUgb2Ygd2hhdCB0byBkbyB3aXRoIGZvcm0gc3VibWlzc2lvbiBmb3IgSVJJ cyBpcyBhY3R1YWxseSBvbmUgb2YgDQp0aGUgY3VycmVudGx5IG9wZW4gaXNzdWVzIGZvciB0aGUg SVJJIHNwZWMuIFBsZWFzZSBzZWUgDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsL2ly aS1lZGl0LyNJUkktYW5kLWZvcm1zLTEwNy4NCg0KQXQgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNo aXZlcy9QdWJsaWMvcHVibGljLWlyaS8yMDA3SnVsLzAwMDAuaHRtbCwNCkkgd3JpdGUgIldoZXJl IGV4YWN0bHkgaXMgdGhlIGJvdW5kYXJ5IGJldHdlZW4gdGhlc2UgdHdvDQpiZWhhdmlvdXJzPyIu DQoNCldoYXQgSSBtZWFuIGlzIHRoZSBmb2xsb3dpbmcuIFF1ZXJ5IHBhcnRzIGV4aXN0Og0KYSkg aW4gImZyZWVzdGFuZGluZyIgSVJJcywgZS5nLiBvbiBhIG5hcGtpbiwgb3Igd2hlbiB0eXBlZCBp bnRvDQogICAgdGhlIGFkZHJlc3MgZmllbGQgb2YgYSBicm93c2VyLg0KYikgaW4gcGxhaW4gbGlu a3MsIGUuZy4gYUBocmVmLCBvciBpbWdAc3JjLC4uLg0KYykgd2hlbiBjcmVhdGVkIGFzIHBhcnQg b2YgYSBmb3JtIHN1Ym1pc3Npb24NCg0KSXQgc2VlbXMgY2xlYXIgdG8gbWUgdGhhdCBmb3IgYSks IHRoZSBvbmx5IGNob2ljZSB3ZSBoYXZlIGlzIHRvIHVzZSANClVURi04LiBUaGluZ3Mgc3VjaCBh cyAidGhlIHBhZ2UgY3VycmVudGx5IGJlaW5nIGRpc3BsYXllZCBiZWxvdyIgb3IgInRoZSANCmVu Y29kaW5nIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGxhbmd1YWdlIHZlcnNpb24gb2YgdGhlIGJyb3dz ZXIgdXNlZCIganVzdCANCmRvbid0IG1ha2Ugc2Vuc2UuDQoNCkl0IGFsc28gc2VlbXMgY2xlYXIg dG8gbWUgdGhhdCBmb3IgYyksIHVzaW5nIHRoZSBlbmNvZGluZyBvZiB0aGUgDQplbmNsb3Npbmcg cGFnZSBpcyBhcyByZWFzb25hYmxlIGEgY2hvaWNlIGFzIGl0IGFsd2F5cyB3YXMuIFRoaXMgY2Fu IGJlIA0KaGFuZGxlZCBjb21wbGV0ZWx5IG91dHNpZGUgYW55IElSSS1yZWxhdGVkIHNwZWMsIGFu ZCBhcyBmYXIgYXMgSSBjYW4gDQpzZWUsIHNlZW1zIHRvIGhhdmUgYmVlbiBkb25lIGFscmVhZHkN CihzZWUgaHR0cDovL3d3dy53My5vcmcvVFIvaHRtbDUvZm9ybXMuaHRtbCN1cmwtZW5jb2RlZC1m b3JtLWRhdGEsDQpzdGVwIDYuMi4xOyBzb21lYm9keSBuZWVkcyB0byBjaGVjayB0aGUgb3RoZXIg c3VibWlzc2lvbiBtZXRob2RzLCBvciANCmNvbmZpcm0gdGhhdCB0aGV5IGFyZSBpcnJlbGV2YW50 IGluIHRoaXMgY29udGV4dC4pDQpbT2gsIGFuZCBhY2NlcHQtY2hhcnNldCBvbiBmb3JtcyBpcyBh bGl2ZSBpbiBIVE1MNSwgd2hpY2ggbWVhbnMgdGhhdCANCnRoZXJlIGlzIGFsd2F5cyBhIHdheSB0 byBpbmRpY2F0ZWQgdGhhdCB5b3Ugd2FudCB0aGUgcXVlcnkgcGFydCBpbiBVVEYtOC5dDQooc2Vl IGh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw1L2Zvcm1zLmh0bWwjYXR0ci1mb3JtLWFjY2VwdC1j aGFyc2V0KQ0KSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIHBvaW50IG91dCBpbiBhIGd1aWRl bGluZSB0byBhdXRob3JzIHRoYXQgYSANCnNpbmdsZSB2YWx1ZSwgcHJlZmVycmFibHkgVVRGLTgs IGlzIGJlc3QuXQ0KDQpTbywgYikgaXMgcmVhbGx5IHRoZSBoYXJkIGNhc2UuIEkgZGVmaW5pdGVs eSB3b3VsZCBoYXZlIHByZWZlcnJlZCBpZiANCnRoaXMgd2VudCB3aXRoIFVURi04LiBUaGUgdGVz dCBwYWdlIG1lbnRpb25lZCBhdA0KaHR0cHM6Ly9idWd6aWxsYS5tb3ppbGxhLm9yZy9zaG93X2J1 Zy5jZ2k/aWQ9Mjg0NDc0IHRhbGtzIGFib3V0IHByZXNzaW5nIA0KdGhlIHN1Ym1pdCBidXR0b24s IG5vdCBhYm91dCBwcmVzc2luZyBhIGxpbmssIHNvIHRoaXMgbWF5IGhhdmUgYmVlbiBjKSANCnJh dGhlciB0aGFuIGIpLCBidXQgdGhlcmUgaXMgbm8gd2F5IHRvIGNoZWNrIGFueW1vcmUuIEJ1dCBp dCB3b3VsZCANCnByb2JhYmx5IG1ha2Ugc2Vuc2UgdG8gcmVjaGVjayB0byBtYWtlIHN1cmUgdGhh dCBpdCBhbHNvIGFwcGxpZXMgdG8gYikgDQoob3IgcHJvdmlkZSBhIHBvaW50ZXIgdG8gYSB0ZXN0 IHRoYXQncyBzdGlsbCBhdmFpbGFibGUpLg0KDQo+IEkgbW9zdGx5IG1hZGUgbXkgcGVhY2Ugd2l0 aCB0aGlzIGluIGEgSnVuZSAyMDA4DQo+IGRpc2N1c3Npb246DQo+DQo+IFJlOiBleHBlY3RlZCBy ZXN1bHRzIGZvciBVUkkgZW5jb2RpbmcgdGVzdHM/DQo+IGh0dHA6Ly9saXN0cy53My5vcmcvQXJj aGl2ZXMvUHVibGljL3B1YmxpYy1odG1sLzIwMDhKdW4vMDM2OS5odG1sDQo+DQo+DQo+IHAucy4g SSB3aXNoIEkgY291bGQgdGVsbCB0aGUgc3Rvcnkgb2YgdGhlIG5vbi13ZXN0ZXJuDQo+IHNlYXJj aCBlbmdpbmUgcHJvYmxlbS9yZXF1aXJlbWVudCBtb3JlIHN0cmFpZ2h0Zm9yd2FyZGx5LA0KPiBi dXQgSSBzZWVtIHRvIGhhdmUgc29tZSBzb3J0IG9mIHdyaXRlcidzIGJsb2NrLg0KDQpXZWxsLCB0 aGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gYSBzZXJ2ZXIgZ2V0cyBkYXRhIChpbiBhIHBhdGggY29t cG9uZW50LCANCmFuZCBldmVuIG1vcmUgaW4gYSBxdWVyeSBwYXJ0KSwgdGhleSBuZWVkIHRvIGtu b3cgd2hhdCBlbmNvZGluZyBpdCBpcyB0byANCm1ha2Ugc2Vuc2Ugb2YgaXQgYW5kIHByb3ZpZGUg YSByZWFzb25hYmxlIGFuc3dlci4gVGhlIHJlYXNvbiB3aHkgeW91IGFyZSANCmNhbGxpbmcgdGhp cyB0aGUgInNlYXJjaCBlbmdpbmUiIHByb2JsZW0gbWF5IGJlIHRoYXQgdGhpcyBwcm9ibGVtIGlz IA0KbW9zdCBwcm9taW5lbnQgd2l0aCBzZWFyY2ggZW5naW5lcywgYmVjYXVzZSBldmVyeWJvZHkg YWdyZWVzIHRoYXQgcGVvcGxlIA0Kd2FudCB0byBzZWFyY2ggaW4gdGhlaXIgbGFuZ3VhZ2UsIG5v dCBsaW1pdGVkIHRvIFVTLUFTQ0lJLg0KQnV0IGl0IGFwcGxpZXMgdG8gYW55IGtpbmQgb2YgcXVl cnkgcGFydHMuDQoNClNvbWUgc2VhcmNoIGVuZ2luZXMgaGF2ZSB0aGVpciBvd24gd2F5IHRvIHBh c3NpbmcgZW5jb2RpbmcgaW5mb3JtYXRpb24sIA0KYXMgYW4gZXhhbXBsZSwgaW4gDQpodHRwOi8v d3d3Lmdvb2dsZS5jb20vc2VhcmNoP3E9JUU5JTlEJTkyJUU1JUIxJUIxJmllPXV0Zi04Jm9lPXV0 Zi04LCANCiJpZSIgaW5kaWNhdGVzIGlucHV0IGVuY29kaW5nIChpLmUuIHdoYXQncyBzZW50IHRv IHRoZSBzZXJ2ZXIsIGFuZCAib2UiIA0KaW5kaWNhdGVzIG91dHB1dCBlbmNvZGluZyAod2hhdCBz aG91bGQgYmUgc2VudCBiYWNrKS4NCg0KQ3VycmVudGx5LCBJIHJlYWxseSBkb24ndCB1bmRlcnN0 YW5kIHdoeSB3ZSBtb3JlIG9yIGxlc3MgbWFuYWdlZCB0byBtb3ZlIA0KdG8gInBhdGggcGFydCBp cyBVVEYtOCIgZnJvbSBhIHRpbWUgd2hlcmUgcGF0aCBwYXJ0cyBhbHNvIHdoZXJlIGVuY29kZWQg DQppbiB0aGUgZW5jb2Rpbmcgb2YgdGhlIHBhZ2UgdGhhdCBjb250YWluZWQgdGhlIGxpbmssIHdo ZXJlYXMgd2UgaGF2ZW4ndCANCmJlZW4gYWJsZSB0byBtYWtlIHRoaXMgdHJhbnNpdGlvbiBmb3Ig cXVlcnkgcGFydHMuIElzIHRoZSByZWFzb24gdGhhdCANCnBhdGggcGFydHMgYXJlIG11Y2ggbW9y ZSB1c2VkIGluZGVwZW5kZW50IG9mIGFueSBlbGVjdHJvbmljIHN1YnN0cmF0ZSANCnRoYXQgd291 bGQgYWxsb3cgdG8ga25vdyB0aGUgZW5jb2RpbmcgKGUuZy4gc2lkZXMgb2YgYnVzZXMpPyBJcyB0 aGUgDQpyZWFzb24gdGhhdCAidGhlIGVuY29kaW5nIGlzIHRoZSBlbmNvZGluZyBvZiB0aGUgY29u dGFpbmluZyBwYWdlIiB3YXMgDQpjb25zaWRlcmVkIGFzIGJlaW5nIGEgZGVmYWN0byBzdGFuZGFy ZCB3b3J0aCBmb2xsb3dpbmcgZm9yIHF1ZXJ5IHBhcnRzLCANCmJ1dCBqdXN0IGFuIGltcGxlbWVu dGF0aW9uIGFjY2lkZW50IGZvciBwYXRoIHBhcnRzPyBXYXMgaXQgdGhhdCBSRkMgMzk4NyANCihh bmQgdGhlIGRyYWZ0cyBsZWFkaW5nIHVwIHRvIGl0KSB3ZXJlIG5vdCBjbGVhciBlbm91Z2ggb24g aG93IHRvIGhhbmRsZSANCnF1ZXJ5IHBhcnRzLCBhbmQgaG93IHRoaXMgcmVsYXRlZCB0byBmb3Jt IHN1Ym1pc3Npb24/DQpJcyBpdCB0aGF0IGNnaSBzY3JpcHRzIGFuZCB0aGUgbGlrZSAod2hpY2gg dXN1YWxseSBwcm9jZXNzIHF1ZXJ5IHBhcnRzKSANCmFyZSBtdWNoIG1vcmUgZGlmZmljdWx0IHRv IGNoYW5nZSB0aGFuIHRoZSBzZXJ2ZXJzIHRoZW1zZWx2ZXMgKHdoaWNoIA0KdXN1YWxseSBwcm9j ZXNzIHBhdGggcGFydHMpPyBXYXMgaXQgdGhhdCBJRSBtYWRlIHRoZSBkZWNpc2lvbiwgYXQgYSB0 aW1lIA0Kd2hlcmUgaXQgY291bGQgaGF2ZSBnb25lIGJvdGggd2F5cywgYnV0IHRoYXQgbm93LCB0 aGVyZSBpcyBtdWNoIG1vcmUgDQppMThuIGNvbnRlbnQsIGFuZCBpdCdzIGhhcmRlciB0byBjaGFu Z2U/DQoNClJlZ2FyZHMsICAgIE1hcnRpbi4NCg0KDQoNCj4gU29tZWJvZHkgZWxzZSBjYXJlIHRv IGdpdmUgaXQgYSB0cnk/IFRpbUJMPyBJYW4/DQo+IEhlbnJpPw0KPg0KDQotLSANCiMtIyBNYXJ0 aW4gSi4gRMO8cnN0LCBQcm9mZXNzb3IsIEFveWFtYSBHYWt1aW4gVW5pdmVyc2l0eQ0KIy0jIGh0 dHA6Ly93d3cuc3cuaXQuYW95YW1hLmFjLmpwICAgbWFpbHRvOmR1ZXJzdEBpdC5hb3lhbWEuYWMu anANCg0K From cfinss@dial.pipex.com Fri May 8 10:56:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18113A685E for ; Fri, 8 May 2009 10:56:22 -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.249, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydVCnA5fYolg for ; Fri, 8 May 2009 10:56:21 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 71CD43A6FD2 for ; Fri, 8 May 2009 10:56:16 -0700 (PDT) X-Trace: 101204944/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.61/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.61 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEAP8PBEo+vBM9/2dsb2JhbACDKEyKYsJBB4ImB4FJBYg3 X-IronPort-AV: E=Sophos;i="4.40,318,1238972400"; d="scan'208";a="101204944" X-IP-Direction: IN Received: from 1cust61.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.61]) by smtp.pipex.tiscali.co.uk with SMTP; 08 May 2009 18:57:42 +0100 Message-ID: <007e01c9cffe$09c33280$0601a8c0@allison> From: "tom.petch" To: "Alexey Melnikov" References: <49E58EA2.6050200@isode.com> <49E5E39C.4040001@alcatel-lucent.com> Subject: Re: TLS server identity verification Date: Fri, 8 May 2009 18:48:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Apps Discuss , =JeffH X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 17:56:23 -0000 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Alexey Melnikov" Cc: "Apps Discuss" ; "=JeffH" Sent: Wednesday, April 15, 2009 3:39 PM > Alexey Melnikov wrote: > > Folks, > > The issue of a document describing recommended text/template for server > > identity verification procedure came up again while talking about > > advancing EPP. > > > > As an AD, I would really like for draft-hodges-server-ident-check to be > > published as an RFC. And I know that Chris was keen on this as well. > > Jeff/Bob, do you have any cycles to work on this? > > In the SIP WG, we just requested publication for a draft that > details mutual TLS authentication for SIP servers and clients > (please see http://tools.ietf.org/html/draft-ietf-sip-domain-certs-03). > > This is somewhat related to what Hodges et al. is attempting > to do for generic servers (as opposed to SIP servers specifically.) > That said, I will be more than happy to review or help on > draft-hodges-... as it moves forward. I too am keen to see this move forward and will help in any way I can (once people stop raising DISCUSS against isms I-Ds, an activity which takes precedence at present:-). My interest is in DTLS more than in TLS, as in syslog over DTLS and possibly SNMP over DTLS. I do have a number of pending comments about the I-D awaiting a suitable WG in which to discuss them. Tom Petch > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From Nicolas.Williams@sun.com Fri May 8 14:09:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E313A6D21 for ; Fri, 8 May 2009 14:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bNkeQcerGwG for ; Fri, 8 May 2009 14:09:22 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 9BE633A69C3 for ; Fri, 8 May 2009 14:09:18 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n48LAlvq016381 for ; Fri, 8 May 2009 21:10:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n48LAlUT041425 for ; Fri, 8 May 2009 15:10:47 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n48L18Ic027797; Fri, 8 May 2009 16:01:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n48L15WU027796; Fri, 8 May 2009 16:01:05 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 8 May 2009 16:01:05 -0500 From: Nicolas Williams To: Alexey Melnikov Subject: Re: TLS server identity verification Message-ID: <20090508210105.GJ27701@Sun.COM> References: <49E58EA2.6050200@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E58EA2.6050200@isode.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , =JeffH X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:09:22 -0000 On Wed, Apr 15, 2009 at 08:37:06AM +0100, Alexey Melnikov wrote: > As an AD, I would really like for draft-hodges-server-ident-check to be > published as an RFC. And I know that Chris was keen on this as well. > Jeff/Bob, do you have any cycles to work on this? I agree, please progress draft-hodges-server-ident-check (which, incidentally, is currently expired). If you update the I-D I will send comments. Nico -- From shinta@sfc.wide.ad.jp Thu May 14 08:31:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3843828C2D5 for ; Thu, 14 May 2009 08:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.393 X-Spam-Level: ** X-Spam-Status: No, score=2.393 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVL3gMGo-mpr for ; Thu, 14 May 2009 08:31:49 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 19DB428C2E4 for ; Thu, 14 May 2009 08:31:30 -0700 (PDT) Received: from [126.18.84.182] (softbank126018084182.bbtec.net [126.18.84.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8A5044C7BA for ; Fri, 15 May 2009 00:38:06 +0900 (JST) Date: Fri, 15 May 2009 00:32:58 +0900 From: Shinta Sugimoto To: apps-discuss@ietf.org Subject: request for review: multihome shim API Message-Id: <20090514234539.9459.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 15:31:50 -0000 Dear all, I am co-authoring an internet draft [1] titled "Socket Application Program Interface (API) for Multihoming Shim". I appreciate if you could read the draft and give us feedbacks. Please note that we are planning to make this document as an informational RFC, and we believe that getting feedbacks from application programmers and reflecting those to the document are important. [1] http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-08 Let me briefly explain what the draft is about. As the title shows, the draft defines a set of extensions to the socket API to provide applications additional control on the locator management. The API is for applications that are running on top of an IP endhost that employs an ID/Locator separation mechanism (we call it "shim"). Examples of shim protocols are HIP [2] and SHIM6 [3]. The most important feature of shim protocol is to provide stable identifier to the upper layer protocols so that they can use it as an communication endpoint. The shim allows applications to continue using the stable identifier even when the host changes its attachment point to the network (e.g., in case of rehoming event under multihome environment, or L3 handover under mobile environment). The implication of the shim protocol running inside the IP layer is that it hides locators from the upper layer protocols. That is certainly a good feature for achieving session continuity as mentioned above. However, we believe it may still be useful for applications to acquire control on locator management. Locator management includes specifying locator for outbound IP traffic and knowing the locators that appear in the wire packet formats. Without the API, applications cannot perform locator management. One example where application may benefit by having locator management is that application may want select particular path (e.g., for achieving better transport performance) under multihomed environment. Any feedbacks are very welcome. Thank you for your attention. [2] http://www.ietf.org/rfc/rfc5201.txt [3] http://tools.ietf.org/html/draft-ietf-shim6-proto Regards, Shinta From patrik@frobbit.se Tue May 26 22:44:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152103A6E85 for ; Tue, 26 May 2009 22:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZIXWsmP4V+J for ; Tue, 26 May 2009 22:44:35 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 8D1583A6B30 for ; Tue, 26 May 2009 22:44:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 9FCBC5468BB7 for ; Wed, 27 May 2009 07:46:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JsBiCYxuJDh for ; Wed, 27 May 2009 07:46:15 +0200 (CEST) Received: from [192.168.1.114] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id F36465468BB0 for ; Wed, 27 May 2009 07:46:14 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: apps-discuss@ietf.org Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-955485352" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Structured data over TCP? Date: Wed, 27 May 2009 07:46:13 +0200 X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 05:44:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5-955485352 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit It was many years ago popular to use line breaks as delimiters in data, and on each line have essentially attribute/value pairs. Then we got XML that today seems to be what people want to use (because there are libraries, and tons of programmers that can (not?) implement XML parsers). We also have "content-length prefixed" XML data, that make things sort of simpler. Sort of in parallell, we have xmlrpc, that to some degree solve slightly different problems. Personally, I have lately looked at JSON, and after serializing data and then use Netstrings (http://cr.yp.to/proto/netstrings.txt), I must say I really like it. For those that do not know Netstrings, here is an example from the spec: > For example, the string "hello world!" is encoded as <31 32 3a 68 65 > 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The > empty string is encoded as "0:,". Implementing is very simple, and you know how many bytes to read. An example JSON-netstring thing can look like (for a 3-object array with a hash as the third object, where the hash as one entry): 29:[1, "info", {"msg": "Hello"}], In the DNS provisioning world we have come up with epp (RFC 3730) that has a binding to TCP (RFC 3734). The binding is a prefixed-based XML blob that is passed over the wire: > EPP Data Unit Format (one tick mark represents one bit position): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | EPP XML Instance | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Now, we need some more protocols here (between DNS operator and the registrar), and the question is whether the same mechanism is recommended, or whether one should use something else? Do Apps Area have any general feeling about this? Patrik --Apple-Mail-5-955485352 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKHNOlrMabGguI180RAlHrAJ0VWHstKkotNJK0+oXChm+MLPRzHQCggJkz //qT9Lkf7BDpw3MrULspBCk= =4QBG -----END PGP SIGNATURE----- --Apple-Mail-5-955485352-- From duerst@it.aoyama.ac.jp Wed May 27 02:55:41 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA5C3A6F4D for ; Wed, 27 May 2009 02:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igc-pdoB1xbP for ; Wed, 27 May 2009 02:55:39 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 2F47B3A6986 for ; Wed, 27 May 2009 02:55:38 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n4R9v9XN025284 for ; Wed, 27 May 2009 18:57:10 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 51f0_be8a48c2_4aa4_11de_9b1f_001d0969ab06; Wed, 27 May 2009 18:57:09 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34646) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 27 May 2009 18:55:36 +0900 Message-ID: <4A1D0E50.1000006@it.aoyama.ac.jp> Date: Wed, 27 May 2009 18:56:32 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Structured data over TCP? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 09:55:41 -0000 Hello Patrik, Some points, not necessarily in any particular order: - I haven't been able to figure out what the trailing ',' in netstrings is for. Any idea? - Netstrings don't say what encoding the data is in; that needs to be settled separately. XML can handle many character encodings if necessary, with sensible defaults, and there is no chance character encoding issues get forgotten. Json seems to be UTF-8 only in practice, which in most cases is about the best you can do these days. - Json's data types are closer to the data types available in many (especially dynamic) programming languages when compared with XML. XML has the advantage that it can represent both data as well as (textual) documents. The later would have to be done with a hopeless hack in Json. - Json can be directly interpreted in JavaScript. Some lazy developer may do it. But it would be an extremely bad idea, because it creates great security holes. - Both Json and XML are widely used on the Web, in what's called Ajax. But there are usually no length prefixes in either case. - There is RFC 3470 for the use of XML in the IETF. Please have a look if you haven't already done so. I'm not sure there is something similar for Json. - You say "Now, we need some more protocols here", but to me, it looks more like you want to exchange some more data. Some people might disagree, but I think there is absolutely no need to invent a new protocol every time some data has to be transferred. - Whether you call it "more protocols" or just "more data formats", if I were at either side of the data exchange, I wouldn't so much care about whether XML is easier to implement or Json or what, but I'd really hate to have a ton of different protocols/formats, each with a different technology. So unless the community involved thinks that this EPP Data Unit Format is hopelessly broken, I'd use the same scheme for all the other protocols/formats. Regards, Martin. On 2009/05/27 14:46, Patrik Fältström wrote: > It was many years ago popular to use line breaks as delimiters in data, > and on each line have essentially attribute/value pairs. > > Then we got XML that today seems to be what people want to use (because > there are libraries, and tons of programmers that can (not?) implement > XML parsers). We also have "content-length prefixed" XML data, that make > things sort of simpler. > > Sort of in parallell, we have xmlrpc, that to some degree solve slightly > different problems. > > Personally, I have lately looked at JSON, and after serializing data and > then use Netstrings (http://cr.yp.to/proto/netstrings.txt), I must say I > really like it. > > For those that do not know Netstrings, here is an example from the spec: > >> For example, the string "hello world!" is encoded as <31 32 3a 68 65 >> 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The empty >> string is encoded as "0:,". > > Implementing is very simple, and you know how many bytes to read. An > example JSON-netstring thing can look like (for a 3-object array with a > hash as the third object, where the hash as one entry): > > 29:[1, "info", {"msg": "Hello"}], > > In the DNS provisioning world we have come up with epp (RFC 3730) that > has a binding to TCP (RFC 3734). The binding is a prefixed-based XML > blob that is passed over the wire: > >> EPP Data Unit Format (one tick mark represents one bit position): >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Total Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | EPP XML Instance | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Now, we need some more protocols here (between DNS operator and the > registrar), and the question is whether the same mechanism is > recommended, or whether one should use something else? > > > Do Apps Area have any general feeling about this? > > Patrik > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From john-ietf@jck.com Wed May 27 04:54:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237F83A6F5F for ; Wed, 27 May 2009 04:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGkr4R92F2I4 for ; Wed, 27 May 2009 04:54:03 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 479A13A6A71 for ; Wed, 27 May 2009 04:54:02 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M9Hj7-000Fv3-Me; Wed, 27 May 2009 07:55:21 -0400 Date: Wed, 27 May 2009 07:55:20 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Subject: Re: Structured data over TCP? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 11:54:04 -0000 Patrik, More on this when I've had time to study the Netstrings spec, but a quick history review for those who may not remember... --On Wednesday, May 27, 2009 07:46 +0200 Patrik = F=C3=A4ltstr=C3=B6m wrote: >... > For those that do not know Netstrings, here is an example from > the spec: >=20 >> For example, the string "hello world!" is encoded as <31 32 >> 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello >> world!,". The empty string is encoded as "0:,". This is one of the oldest string formats around. Modulo the fact that first-generation FORTRAN didn't have lower-case characters, it would have been written as "12Hhello world!". The machine-level coding of character strings on the world-oriented machines of that generation would have been=20 First word: 00...1100 (binary, left padded, e.g., 12) Coded characters packed into as many subsequent words as needed, with trailing padding. =20 On the one character-oriented machine of that generation I remember, strings were delimited by special "word marks"; I can't remember whether the length was stored as well. In that generation, many of us learned that people really are not good at counting characters, at least not if there are significantly more than a half-dozen of them. That led in only slightly later generations of languages to, e.g., 'hello world!' with the compiler doing the counting as needed, but length-string pairs remained the most common form until C became prevalent. As you know, the DNS uses that form internally, so it certainly isn't new to the Internet either. Coming full circle? john From patrik@frobbit.se Wed May 27 05:39:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8363A6E2C for ; Wed, 27 May 2009 05:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.271 X-Spam-Level: X-Spam-Status: No, score=-0.271 tagged_above=-999 required=5 tests=[AWL=-1.878, BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rPmdHvZGb83 for ; Wed, 27 May 2009 05:39:23 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 267583A685F for ; Wed, 27 May 2009 05:39:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 1A828547F722; Wed, 27 May 2009 14:39:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZJNbd0Fkk+T; Wed, 27 May 2009 14:39:47 +0200 (CEST) Received: from 95.209.11.232.bredband.tre.se (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 7F3C3547F70F; Wed, 27 May 2009 14:39:45 +0200 (CEST) Message-Id: <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: =?ISO-8859-1?Q?=22Martin_J._D=FCrst=22?= In-Reply-To: <4A1D0E50.1000006@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-980293847" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Wed, 27 May 2009 14:39:42 +0200 References: <4A1D0E50.1000006@it.aoyama.ac.jp> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 12:39:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25-980293847 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 27 maj 2009, at 11.56, Martin J. D=FCrst wrote: > Some points, not necessarily in any particular order: > > - I haven't been able to figure out what the trailing ',' in =20 > netstrings is for. Any idea? I like it being there, because if you end up being out of sync when =20 parsing, you can find "the next string" by looking for ',' followed by =20= [LEN] followed by a ':'. > - Netstrings don't say what encoding the data is in; that needs to =20 > be settled separately. XML can handle many character encodings if =20 > necessary, with sensible defaults, and there is no chance character =20= > encoding issues get forgotten. Json seems to be UTF-8 only in =20 > practice, which in most cases is about the best you can do these days. Correct. > - Json's data types are closer to the data types available in many =20 > (especially dynamic) programming languages when compared with XML. =20 > XML has the advantage that it can represent both data as well as =20 > (textual) documents. The later would have to be done with a hopeless =20= > hack in Json. Agree. And I only talk about "structured data" in my case. I do not =20 know how many discussions I have been in about XML (note: I am not an =20= XML pro, the contrary) on whether things should be foo or = =20 zfoo etc. And the mapping back and forth between =20= a data structure and XML seems to be "kind of interesting". Parsing =20 XML seems to be ok, but generating... The JSON libraries I have been working with lately very very easily =20 both produces and parses the serialized data. > - Json can be directly interpreted in JavaScript. Some lazy =20 > developer may do it. But it would be an extremely bad idea, because =20= > it creates great security holes. Agree. > - Both Json and XML are widely used on the Web, in what's called =20 > Ajax. But there are usually no length prefixes in either case. Ok, I do not know enough about this. That is why I propose the addition of netstring format for the =20 serialized JSON data. And that is why the XML blob in epp as a length =20= prefix. > - There is RFC 3470 for the use of XML in the IETF. Please have a =20 > look if you haven't already done so. I'm not sure there is something =20= > similar for Json. I will look again at it. > - You say "Now, we need some more protocols here", but to me, it =20 > looks more like you want to exchange some more data. Some people =20 > might disagree, but I think there is absolutely no need to invent a =20= > new protocol every time some data has to be transferred. I agree with you here, but the is your point that epp should be used =20 also between DNS provider and registrar? FYI: epp is _extremely_ complex as the data model is "interesting". A =20= normal DNS operator definitely do not need that power. But they might =20= need other things. That is not included in the epp protocol (but could =20= theoretically be managed by extensions). epp is very very optimized for the registry/registrar model. > - Whether you call it "more protocols" or just "more data formats", =20= > if I were at either side of the data exchange, I wouldn't so much =20 > care about whether XML is easier to implement or Json or what, but =20 > I'd really hate to have a ton of different protocols/formats, each =20 > with a different technology. So unless the community involved thinks =20= > that this EPP Data Unit Format is hopelessly broken, I'd use the =20 > same scheme for all the other protocols/formats. I would say "no" to use of epp between dns operator and registrar. Patrik --Apple-Mail-25-980293847 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKHTSOrMabGguI180RAmKHAJ4/hO8w1dqWld7oDxA957yxQGidjACfYAQ7 Fa+Vp7XQqX/sOLuB2taQv0g= =cCcC -----END PGP SIGNATURE----- --Apple-Mail-25-980293847-- From patrik@frobbit.se Wed May 27 05:42:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C7C3A6C78 for ; Wed, 27 May 2009 05:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD1ak8lDGqVn for ; Wed, 27 May 2009 05:42:22 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 5AF5F3A685F for ; Wed, 27 May 2009 05:42:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 65FA5547F950; Wed, 27 May 2009 14:43:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-K8+Kh2-cdr; Wed, 27 May 2009 14:43:30 +0200 (CEST) Received: from 95.209.11.232.bredband.tre.se (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 4A987547F949; Wed, 27 May 2009 14:43:29 +0200 (CEST) Message-Id: <589AB1AC-28C1-4557-ACFB-679705154987@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: John C Klensin In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27-980518374" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Wed, 27 May 2009 14:43:26 +0200 References: X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 12:42:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-27-980518374 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 maj 2009, at 13.55, John C Klensin wrote: > Coming full circle? I think so, as I have lost count on how many times I have seen quoting issues in XML data passed around...counting bytes is sometimes pretty simple...and together with the JSON format that, as Martin stated so well, is better for data structures (but not as good at text)...that was something I liked. But, this is exactly why I also enjoy this discussion. I think the discussion is need. paf --Apple-Mail-27-980518374 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKHTVurMabGguI180RAg2QAJ9SkaaqbgQxeH6WJ9avJr70JDAKpgCfYfIK 8GTGQmievc736hAFyzM83c4= =pxK2 -----END PGP SIGNATURE----- --Apple-Mail-27-980518374-- From patrik@frobbit.se Wed May 27 06:07:24 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A193A3A67E1 for ; Wed, 27 May 2009 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tFMDHAQgiC7 for ; Wed, 27 May 2009 06:07:23 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 6175B3A67AA for ; Wed, 27 May 2009 06:07:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 74BBE548087A; Wed, 27 May 2009 15:07:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yVhBZYYdHSq; Wed, 27 May 2009 15:07:10 +0200 (CEST) Received: from 95.209.11.232.bredband.tre.se (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id 68C145480872; Wed, 27 May 2009 15:07:09 +0200 (CEST) Message-Id: <139FAF6C-DA37-4535-8AAE-940D7D963A9D@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF0702A6AA30@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-30-981936628" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Wed, 27 May 2009 15:07:05 +0200 References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <046F43A8D79C794FA4733814869CDF0702A6AA30@dul1wnexmb01.vcorp.ad.vrsn.com> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:07:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-30-981936628 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 maj 2009, at 14.47, Hollenbeck, Scott wrote: >> epp is very very optimized for the registry/registrar model. > > Some of the current mappings are definitely optimized for that > model, but I'm not so sure that the same can be said of the protocol > core itself. If one were to throw out the domain and host mappings, > for example (instead of trying to extend them), and create a new DNS > operator mapping, couldn't the more "interesting" aspects of the > registry/registrar model be overcome? Agree. The complex data structure of epp is because you have domain, contact and hosts as separate objects, and then sponsoring clients for each one of them. I.e. the data model is kept coherent by pointers in the objects that the client have to manage themselves. Specifically when the registries have set up their own models on what happens when transfers of objects are done etc. A simpler model is possible when someone that have authenticated have access to certain domains (that they are holder or techc for, for example). Then it is possible to in a very simple way "just" upload DS for the domain (and that command is replacing _all_ ds that is stored). The XML for doing that operation is quite complex in epp... Just because epp is a generalized protocol for the operations a registrar is to make in a registry (transfer, register, update records etc). My JSON blob for replacing DS data for a domin do for example look like this (with one key only): {"dsdata": [{"keyTag": "59344", "digestType": "1", "digest": "529C963AFEA3F938B87E277405072316639B18B0", "alg": "5"}], "domain": "example1.se"} This results in sort of the following two epp commands: example1.se 0 46645-013555262222 example1.se 59344 5 1 529C963AFEA3F938B87E277405072316639B18B0 46645-013555262222 Patrik --Apple-Mail-30-981936628 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKHTr5rMabGguI180RAkFRAJ9Ao6OFDs+dnMgkrdCKaggu1BwL9QCfTf5l T7OlDmo2KPJw3buEsbgKgZQ= =o8as -----END PGP SIGNATURE----- --Apple-Mail-30-981936628-- From shollenbeck@verisign.com Wed May 27 06:10:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8463A696F for ; Wed, 27 May 2009 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=2.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65TD27YA+EkD for ; Wed, 27 May 2009 06:10:24 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 283F33A68DE for ; Wed, 27 May 2009 06:10:24 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n4RCb8V8006471; Wed, 27 May 2009 08:37:08 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 13:47:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Structured data over TCP? Date: Wed, 27 May 2009 08:47:42 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702A6AA30@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Structured data over TCP? Thread-Index: AcneyGr2EF8SRN7ETk2zl593TQw9mAAAFNDQ References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-OriginalArrivalTime: 27 May 2009 12:47:43.0466 (UTC) FILETIME=[53EDDCA0:01C9DEC9] Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:10:25 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Patrik = F=E4ltstr=F6m > Sent: Wednesday, May 27, 2009 8:40 AM > To: "Martin J. D=FCrst" > Cc: apps-discuss@ietf.org > Subject: Re: Structured data over TCP? [snip] I'm more than a disinterested third party when it comes to EPP, so = please take my comments with an appropriately-sized grain of salt. > I agree with you here, but the is your point that epp should=20 > be used also between DNS provider and registrar? >=20 > FYI: epp is _extremely_ complex as the data model is=20 > "interesting". A normal DNS operator definitely do not need=20 > that power. But they might need other things. That is not=20 > included in the epp protocol (but could theoretically be=20 > managed by extensions). >=20 > epp is very very optimized for the registry/registrar model. Some of the current mappings are definitely optimized for that model, = but I'm not so sure that the same can be said of the protocol core = itself. If one were to throw out the domain and host mappings, for = example (instead of trying to extend them), and create a new DNS = operator mapping, couldn't the more "interesting" aspects of the = registry/registrar model be overcome? -Scott- From vkg@alcatel-lucent.com Wed May 27 06:37:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397BB3A6ED1 for ; Wed, 27 May 2009 06:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-vRkqvsJBNe for ; Wed, 27 May 2009 06:37:31 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A70A53A6DA2 for ; Wed, 27 May 2009 06:37:29 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n4RDbjwV002400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 08:37:45 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n4RDbiRX002335; Wed, 27 May 2009 08:37:44 -0500 (CDT) Message-ID: <4A1D4228.7050704@alcatel-lucent.com> Date: Wed, 27 May 2009 08:37:44 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John C Klensin Subject: Re: Structured data over TCP? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:37:32 -0000 John C Klensin wrote: > This is one of the oldest string formats around. [...] This is very interesting. The format specified by Patrik is known to me as bencoding (binary encoding) as used by BitTorrent. While BitTorrent does not create a hex representation, "Hello World!" will be bencoded as 12:Hello World!, and an integer 3 base 10 will be encoded as i3e ('i' for integer and 'e' delimiting end of integer). There are similar constructs to represent lists and dictionaries as well. I had always assumed that this was a BitTorrent-specific format, but it appears that the format has a rich history. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From andy@hxr.us Wed May 27 06:43:09 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547E23A67AA for ; Wed, 27 May 2009 06:43:09 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E8Y3YjIIyYr for ; Wed, 27 May 2009 06:43:08 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id A67FF3A6A48 for ; Wed, 27 May 2009 06:43:08 -0700 (PDT) Received: from dhcp-219.arin.net ([::ffff:192.149.252.11]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 27 May 2009 09:43:46 -0400 id 015842F3.4A1D4392.00002D38 Message-Id: <4D816A66-1BD7-4136-8DFE-EC94E1BD9178@hxr.us> From: Andrew Newton To: "=?ISO-8859-1?Q?=22Patrik_F=E4ltstr=F6m=22?=" In-Reply-To: <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Structured data over TCP? Date: Wed, 27 May 2009 09:43:46 -0400 References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> X-Mailer: Apple Mail (2.930.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 13:43:09 -0000 On May 27, 2009, at 8:39 AM, Patrik F=E4ltstr=F6m wrote: >> - Both Json and XML are widely used on the Web, in what's called =20 >> Ajax. But there are usually no length prefixes in either case. > > Ok, I do not know enough about this. > > That is why I propose the addition of netstring format for the =20 > serialized JSON data. And that is why the XML blob in epp as a =20 > length prefix. Just a guess here, but this is probably due to AJAX using HTTP and =20 HTTPs content length header. -andy= From fanf2@hermes.cam.ac.uk Wed May 27 08:57:15 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC7C3A698B for ; Wed, 27 May 2009 08:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaGKYKcxpizS for ; Wed, 27 May 2009 08:57:13 -0700 (PDT) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 7A2463A6EBC for ; Wed, 27 May 2009 08:57:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47322) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1M9LVX-0000WE-1I (Exim 4.70) (return-path ); Wed, 27 May 2009 16:57:35 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1M9LVX-0006iL-CV (Exim 4.67) (return-path ); Wed, 27 May 2009 16:57:35 +0100 Date: Wed, 27 May 2009 16:57:35 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Structured data over TCP? In-Reply-To: <589AB1AC-28C1-4557-ACFB-679705154987@frobbit.se> Message-ID: References: <589AB1AC-28C1-4557-ACFB-679705154987@frobbit.se> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-361027872-1243439855=:4749" Sender: Tony Finch Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 15:57:15 -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. --1870870024-361027872-1243439855=:4749 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 27 May 2009, Patrik F=E4ltstr=F6m wrote: > > counting bytes is sometimes pretty simple... Implementations of byte-count protocols have a history of security vulnerabilities associated with framing errors. It's evidently more difficult than it seems. Tony. --=20 f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. --1870870024-361027872-1243439855=:4749-- From Nicolas.Williams@sun.com Wed May 27 09:06:22 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6AB28C1DC for ; Wed, 27 May 2009 09:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJIRyk752HEC for ; Wed, 27 May 2009 09:06:21 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 2C2D23A6F42 for ; Wed, 27 May 2009 09:06:03 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RG7KWm025117 for ; Wed, 27 May 2009 16:07:20 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4RG7J0t058741 for ; Wed, 27 May 2009 10:07:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RFnvmb014090; Wed, 27 May 2009 10:49:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RFnq7V014089; Wed, 27 May 2009 10:49:52 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 27 May 2009 10:49:52 -0500 From: Nicolas Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Subject: Re: Structured data over TCP? Message-ID: <20090527154952.GW29258@Sun.COM> References: 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.7i Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:06:22 -0000 On Wed, May 27, 2009 at 07:46:13AM +0200, Patrik Fältström wrote: > Now, we need some more protocols here (between DNS operator and the > registrar), and the question is whether the same mechanism is > recommended, or whether one should use something else? > > Do Apps Area have any general feeling about this? You left out a great many other encodings (like all the ASN.1 encodings, XDR, ...). It's all the same to me. Typically the main issue is: can the selected encoding be easily implemented by the existing implementors and new interested implementors? Typically the answer to that question in regards to ASN.1 encodings is "no". The lack of a good, simple syntax+encoding with lots of popular opensource tools tends to result in every new protocol having a new encoding :( A few examples: - LDAP -> ASN.1/DER - IMAP -> text-based protocol - SSHv2 -> informal syntax + custom encoding - DNS -> ASCII art representations of bits-on-the-wire as syntax and hand-crafted encoding - DIGEST-MD5 -> ABNF syntax with straightforward encoding derived from the ABNF I'm afraid it's really the wild west out there: pick an off-the-shelf syntax/encoding, or just make one up. I tend to prefer the use of a formal syntax -- ASN.1, ABNF, XDR, ... Nico -- From timbray@gmail.com Wed May 27 09:15:34 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EFB3A6F81 for ; Wed, 27 May 2009 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSPGAnDcWZ8y for ; Wed, 27 May 2009 09:15:33 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 3FA1E3A6882 for ; Wed, 27 May 2009 09:15:29 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so4788557yxb.49 for ; Wed, 27 May 2009 09:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QvFN6vKvhOxzjOimpGL9cvHlqFBNMG6Q6TxguIZWXTk=; b=DKk31hb7ViutoAZUlWDZYspY0mJ1OBqXhMFkB/txnqtESqEpfDiNxQse3vYsiUghd9 80wt6rLbxknegOiAsnXltFQCtGgeHTqnQwB2a7iHEUG6RRStvOmENOZCpm2lyvV6ocTt 5+tgUDW/LMWOtt5pQICaImf8gEN5ljPEn9YOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vmdgTKAkjbTf426PAQvuX52GzHg9sLrfF3xFTaPCYoBqGXeUdMpJnoDBik7ilHhou+ pDuZqQTKTIMdzN8kmnXEX/1dln2p1dAO8fXvlR7DwwO170N5SUQ9I19q2YNuLqpgj8HW EUAh+a257dPez18MGkXvmMrMOdhrrmSwa6DJU= MIME-Version: 1.0 Sender: timbray@gmail.com Received: by 10.101.71.3 with SMTP id y3mr208368ank.158.1243441030582; Wed, 27 May 2009 09:17:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2009 09:17:10 -0700 X-Google-Sender-Auth: 22a20c612320b8ca Message-ID: <517bf110905270917m1032a9e2md146f4c88f2d6d8@mail.gmail.com> Subject: Re: Structured data over TCP? From: Tim Bray To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 16:15:34 -0000 2009/5/26 Patrik F=E4ltstr=F6m : > Do Apps Area have any general feeling about this? I was going to start typing in a lengthy answer but then I remembered I gave a tutorial at IETF70 on the choice of data formats for use in Internet Protocols. It's centered around XML but I think covers many of the other issues that have come up in this. Available for your reading pleasure at http://www.tbray.org/tmp/IETF70.pdf -Tim From Nicolas.Williams@Sun.COM Wed May 27 10:35:12 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724B23A685A for ; Wed, 27 May 2009 10:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4H2-A82cdBW for ; Wed, 27 May 2009 10:35:11 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 0C5B73A677D for ; Wed, 27 May 2009 10:35:10 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RH0deI025540 for ; Wed, 27 May 2009 17:00:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4RH0aJd035600 for ; Wed, 27 May 2009 11:00:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RG5jts014104; Wed, 27 May 2009 11:05:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RG5fbW014103; Wed, 27 May 2009 11:05:41 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 27 May 2009 11:05:41 -0500 From: Nicolas Williams To: Tony Finch Subject: Re: Structured data over TCP? Message-ID: <20090527160540.GY29258@Sun.COM> References: <589AB1AC-28C1-4557-ACFB-679705154987@frobbit.se> 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.7i Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:35:12 -0000 On Wed, May 27, 2009 at 04:57:35PM +0100, Tony Finch wrote: > On Wed, 27 May 2009, Patrik Fältström wrote: > > > > counting bytes is sometimes pretty simple... > > Implementations of byte-count protocols have a history of security > vulnerabilities associated with framing errors. It's evidently more > difficult than it seems. The more redundancy in the encoding, the more bugs in the resulting encoder/decoder code. The TLV encodings of ASN.1 are a good example; compare to less chatty encodings like PER or XDR, or to hand-crafted formats like IP and TCP headers. XML is very chatty, but being text based helps, I think. Nesting structures (bags of stuff) probably hurts too, particularly when variable-length arrays of items with variable-length encodings are involved (e.g., security bugs in XDR have mostly involved XDR arrays). Nico -- From patrik@frobbit.se Wed May 27 10:43:31 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234463A69D5 for ; Wed, 27 May 2009 10:43:31 -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=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO-YNSbVYp8q for ; Wed, 27 May 2009 10:43:30 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 27B143A6BD6 for ; Wed, 27 May 2009 10:43:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6A17C5490004; Wed, 27 May 2009 19:44:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLeLfIuR7A5Y; Wed, 27 May 2009 19:44:35 +0200 (CEST) Received: from [10.101.1.219] (rtp-isp-nat1.cisco.com [64.102.254.33]) by srv01.frobbit.se (Postfix) with ESMTP id 6A8CE548FFF9; Wed, 27 May 2009 19:44:32 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Andrew Newton In-Reply-To: <4D816A66-1BD7-4136-8DFE-EC94E1BD9178@hxr.us> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-998579251" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Wed, 27 May 2009 19:44:27 +0200 References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4D816A66-1BD7-4136-8DFE-EC94E1BD9178@hxr.us> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 17:43:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3-998579251 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 27 maj 2009, at 15.43, Andrew Newton wrote: >> That is why I propose the addition of netstring format for the >> serialized JSON data. And that is why the XML blob in epp as a >> length prefix. > > Just a guess here, but this is probably due to AJAX using HTTP and > HTTPs content length header. I think so, but with XML you could also sort of "parse until you hit the end tag", although I guess that is dangerous. Anyone written the actual code that slurp XML from the wire? What did you do? paf --Apple-Mail-3-998579251 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFKHXv7rMabGguI180RAphVAKCQlZjGTW6DKFzd3Xsv2kyRPIW0PwCeMIU5 3S5sfW8NV4Vor6KPYq0Obo8= =c7g9 -----END PGP SIGNATURE----- --Apple-Mail-3-998579251-- From Nicolas.Williams@sun.com Wed May 27 11:03:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AD13A6D7A for ; Wed, 27 May 2009 11:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRXrOJ7NJuRg for ; Wed, 27 May 2009 11:03:24 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 494833A6CD1 for ; Wed, 27 May 2009 11:03:24 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RI4wnO029878 for ; Wed, 27 May 2009 18:04:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4RI4wki022263 for ; Wed, 27 May 2009 12:04:58 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RHlcKc014161; Wed, 27 May 2009 12:47:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RHlZRf014160; Wed, 27 May 2009 12:47:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 27 May 2009 12:47:35 -0500 From: Nicolas Williams To: "Vijay K. Gurbani" Subject: Re: Structured data over TCP? Message-ID: <20090527174734.GB29258@Sun.COM> References: <4A1D4228.7050704@alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1D4228.7050704@alcatel-lucent.com> User-Agent: Mutt/1.5.7i Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:03:25 -0000 On Wed, May 27, 2009 at 08:37:44AM -0500, Vijay K. Gurbani wrote: > John C Klensin wrote: > >This is one of the oldest string formats around. > [...] > > This is very interesting. The format specified by Patrik > is known to me as bencoding (binary encoding) as used by > BitTorrent. While BitTorrent does not create a hex > representation, "Hello World!" will be bencoded as > 12:Hello World!, and an integer 3 base 10 will be encoded > as i3e ('i' for integer and 'e' delimiting end of integer). > There are similar constructs to represent lists and > dictionaries as well. > > I had always assumed that this was a BitTorrent-specific > format, but it appears that the format has a rich history. There is nothing new in the world of data serialization :) In LISP S-expressions are the data serialization format, and S-expressions are also the form of all LISP programs. It doesn't get much simpler than that. And that goes back many decades. Throw in the destructuring-bind macro and you have something not unlike a JSON equivalent of XPath. Perl Data::Dumper, Icon's whatever it was called, etcetera -- all of these are just the equivalents of LISP's serialization scheme, but for languages where the program is written in a very different syntax. The Icon serializer produces output very similar to what you describe is used in BitTorrent. Nico -- From timbray@gmail.com Wed May 27 11:04:04 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5313A6C56 for ; Wed, 27 May 2009 11:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCKSfrKQei85 for ; Wed, 27 May 2009 11:04:04 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 012CB3A6D7A for ; Wed, 27 May 2009 11:04:03 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so4846481yxb.49 for ; Wed, 27 May 2009 11:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5zCnCRB3JSw4FcnZN4gNOS/TDkDKTJmuoQTJ/j2LL90=; b=SgICs16MnlMEGIoA537wUY4S44j+7YwT404uDknGPEYdmHLTcv1E33IvsXU0vCXW0L rfti902YCsTUi44f3GVAfh1bn+IHkiDafJGv7oLQBRTWx2cKLtYt0pZVJcJk/VhzhZFj dAJjVeQzeM0aC6Pt++FdtouaEvcICxsf5toN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qaxmYkWuc/y6IW/soKqdu2jBJMpQN6K2TsuDE3xmge2Z8C6SQh6cWfwt2GDBXDcS35 xLTvENmrL+XZP0x5wRv8mdToWF3amSojRrrrLWLraqR0FgIKW+D1JmpYm+YxtBa253If oRNRAdkVRtv6FErc3m8ztCsxlW2LZH5NShIlU= MIME-Version: 1.0 Sender: timbray@gmail.com Received: by 10.100.166.7 with SMTP id o7mr466654ane.90.1243447543017; Wed, 27 May 2009 11:05:43 -0700 (PDT) In-Reply-To: References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4D816A66-1BD7-4136-8DFE-EC94E1BD9178@hxr.us> Date: Wed, 27 May 2009 11:05:42 -0700 X-Google-Sender-Auth: 5810c54782923c25 Message-ID: <517bf110905271105y586a990dne7a276073b7c6818@mail.gmail.com> Subject: Re: Structured data over TCP? From: Tim Bray To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Andrew Newton X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:04:04 -0000 2009/5/27 Patrik F=E4ltstr=F6m : > I think so, but with XML you could also sort of "parse until you hit the = end > tag", although I guess that is dangerous. That was a semi-explicit design goal: that you could shut the network connection down when you saw the end-tag and not worry if the other end was being sluggish in closing the connection. I used to emphasize this a lot when I was Global Chief XML Salesguy, and people always nodded their heads. > Anyone written the actual code that slurp XML from the wire? Yes. And despite the point above, I've never seen an implementation that actually does close the input stream when it sees the end-tag :) In practice it doesn't seem to have been a problem. -Tim From dhc@dcrocker.net Wed May 27 11:27:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004CD3A6E58 for ; Wed, 27 May 2009 11:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlcgM4PhQFXe for ; Wed, 27 May 2009 11:27:13 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 8A6A93A6818 for ; Wed, 27 May 2009 11:27:12 -0700 (PDT) Received: from [127.0.0.1] (adsl-68-122-33-167.dsl.pltn13.pacbell.net [68.122.33.167]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4RISfaK005491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 11:28:47 -0700 Message-ID: <4A1D8659.6010202@dcrocker.net> Date: Wed, 27 May 2009 11:28:41 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Structured data over TCP? References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> In-Reply-To: <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 27 May 2009 11:28:47 -0700 (PDT) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:27:14 -0000 Patrik Fältström wrote: > On 27 maj 2009, at 11.56, Martin J. Dürst wrote: >> - I haven't been able to figure out what the trailing ',' in >> netstrings is for. Any idea? > > I like it being there, because if you end up being out of sync when > parsing, you can find "the next string" by looking for ',' followed by > [LEN] followed by a ':'. Count-versus-parse is an ancient choice. As computer scientists, we like the determinism and simplicity and presumed efficiency of counting to the end (or using the count to jump directly to the end) rather than scanning for a delimiter. So it's unfortunate to discover that it frequently is a poor choice. For example, in a world of serial communications, parsing isn't necessarily more expensive. And it tends to be more robust, as noted in the above comment. And also as noted earlier, humans don't count very well. So for a scheme that considers the full "lifecycle" of use including human actors, a parsing-based scheme often is actually simpler. On the average, in application space, the human factor tends to dominate the choice, or should, IMO. Of course, it's possible to have a parsing syntax that is ridiculously verbose, and one can argue that XML crosses that line. The only problem is that XML is so popular, the claim that it is too verbose needs some diligent defense. More generally, any existing scheme that has wide deployment gets the benefit of familiarity. So I think any new scheme needs to make a compelling case for superiority that overcomes the community's lack of familiarity with it and, therefore, the considerable community cost of adopting it. Indeed, netstrings appears to be a variant of a very old scheme that has had some use but has not remained popular. For all the apparent benefits of the scheme, one should worry about why its model has not been very popular for applications. One should be especially curious about a counting scheme that includes scanning constructs. While sounding nicely robust, it raises a basic question about the actual utility of the counting. After all, if you still have to build and test the mechanism that uses the scanning construct, why bother with counting? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fanf2@hermes.cam.ac.uk Wed May 27 13:01:25 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D543A6F67 for ; Wed, 27 May 2009 13:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJjpzaHVQ2yl for ; Wed, 27 May 2009 13:01:24 -0700 (PDT) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by core3.amsl.com (Postfix) with ESMTP id 4046928C161 for ; Wed, 27 May 2009 13:01:09 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58925) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1M9PKI-0007St-37 (Exim 4.70) (return-path ); Wed, 27 May 2009 21:02:14 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1M9PKI-0000rp-Um (Exim 4.67) (return-path ); Wed, 27 May 2009 21:02:14 +0100 Date: Wed, 27 May 2009 21:02:14 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dcrocker@bbiw.net Subject: Re: Structured data over TCP? In-Reply-To: <4A1D8659.6010202@dcrocker.net> Message-ID: References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4A1D8659.6010202@dcrocker.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: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 20:01:25 -0000 On Wed, 27 May 2009, Dave CROCKER wrote: > > One should be especially curious about a counting scheme that includes > scanning constructs. While sounding nicely robust, it raises a basic question > about the actual utility of the counting. After all, if you still have to > build and test the mechanism that uses the scanning construct, why bother with > counting? Netstrings are designed to be human-readable (hence the textual encoding of the number and the parser-friendliness) but they still support unencoded binary payloads (no need for byte stuffing). Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From john-ietf@jck.com Wed May 27 14:04:14 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82823A6856 for ; Wed, 27 May 2009 14:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg4FRnRsR6Bw for ; Wed, 27 May 2009 14:04:14 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B6B513A6768 for ; Wed, 27 May 2009 14:04:13 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M9QJt-000CDy-Si; Wed, 27 May 2009 17:05:54 -0400 Date: Wed, 27 May 2009 17:05:52 -0400 From: John C Klensin To: dcrocker@bbiw.net, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Subject: Re: Structured data over TCP? Message-ID: <7506B4121FEAC65A9A87FB97@PST.JCK.COM> In-Reply-To: <4A1D8659.6010202@dcrocker.net> References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4A1D8659.6010202@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 21:04:14 -0000 --On Wednesday, May 27, 2009 11:28 -0700 Dave CROCKER wrote: >... > Count-versus-parse is an ancient choice. As computer > scientists, we like the determinism and simplicity and > presumed efficiency of counting to the end (or using the count > to jump directly to the end) rather than scanning for a > delimiter. > > So it's unfortunate to discover that it frequently is a poor > choice. For example, in a world of serial communications, > parsing isn't necessarily more expensive. And it tends to be > more robust, as noted in the above comment. And also as noted > earlier, humans don't count very well. So for a scheme that > considers the full "lifecycle" of use including human actors, > a parsing-based scheme often is actually simpler. On the other hand, if the structure is long or might involve nesting, parsing-based systems risk loss of state or miscounting delimiters, either of which can have catastrophic results. Counting systems can also fail if systems miscount or some items are lost, but that is a different sort of failure. Often the right solution is a presentation form that uses delimiters, works for users on input and has an intuitive interpretation on display and a transmission (or protocol-level) form that uses counts. It is perhaps not an accident that describes what is done with the DNS. >... > One should be especially curious about a counting scheme that > includes scanning constructs. While sounding nicely robust, > it raises a basic question about the actual utility of the > counting. After all, if you still have to build and test the > mechanism that uses the scanning construct, why bother with > counting? Perhaps more important, if one can determine the end of the same string by _either_ counting or scanning, one immediately has to confront the question of what to do if they yield inconsistent results, e.g., whether that is an error condition that invalidates the string (or data structure) or, if one takes priority, what the other one means. I think the technical term for that sort of situation is "big mess". I agree with Dave that this is an ancient choice. I also suggest (as Dave does indirectly) that we have made most of the possible mistakes several times already and that we should try to avoid reinventing them again if possible. john From dhc@dcrocker.net Wed May 27 15:56:37 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE523A7049 for ; Wed, 27 May 2009 15:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiR46OJb1GPv for ; Wed, 27 May 2009 15:56:36 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id E24B03A6BDA for ; Wed, 27 May 2009 15:56:35 -0700 (PDT) Received: from [127.0.0.1] (adsl-68-122-33-167.dsl.pltn13.pacbell.net [68.122.33.167]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4RMwAqK020773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 May 2009 15:58:15 -0700 Message-ID: <4A1DC581.6050108@dcrocker.net> Date: Wed, 27 May 2009 15:58:09 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Structured data over TCP? References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4A1D8659.6010202@dcrocker.net> <7506B4121FEAC65A9A87FB97@PST.JCK.COM> In-Reply-To: <7506B4121FEAC65A9A87FB97@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 27 May 2009 15:58:15 -0700 (PDT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 22:56:37 -0000 John C Klensin wrote: > On the other hand, if the structure is long or might involve nesting, > parsing-based systems risk loss of state or miscounting delimiters, either of > which can have catastrophic results. That's a fragility argument. As Patrik commented for, the comma in the count-based scheme was for recovery from possible loss of parsing state. So count-based systems aren't immune from the problem. Overall, I'm hard-pressed to believe that ASN.1 is more robust than, say, XML or ABNF. > Counting systems can also fail if systems miscount or some items are lost, > but that is a different sort of failure. Often the right solution is a > presentation form that uses delimiters, works for users on input and has an > intuitive interpretation on display and a transmission (or protocol-level) > form that uses counts. It is perhaps not an accident that describes what is > done with the DNS. DNS uses small, rather simple data objects. That makes the counts model trivial. SNMP uses ASN.1, but that choice was forced onto the SNMP folks in a misguided effort to make its data object compatible with CMIP and was complained about for years by the SNMP folk. As for using different schemes between presentation versus transfer, that invites translation errors. Besides that, the human-computer interface of "display" and "input" are their own environments, not needing an "exchange" encoding standard. If the suggestion is to map from user input to some sort of parsed presentation-layer format and then map that down to some sort of count-based transfer-layer format, I don't understand the benefit. Again, it invites translation error, as well as adding the overhead of the extra translation step. Ultimately, my own view about new meta-formats is that they need to supply a compelling, practical value proposition. A number of existing meta-formats have an enormous installed based of software and experience and clearly function robustly and efficiently. It's not that one can't improve on that. It's that any claim of improvement needs to be compellingly practical. Not just as an exercise in cleanliness or efficiency, but in fixing some current problem among the available choices. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From duerst@it.aoyama.ac.jp Wed May 27 17:47:16 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E343A6A7E for ; Wed, 27 May 2009 17:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MABTqMjooYHb for ; Wed, 27 May 2009 17:47:14 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 88A623A6812 for ; Wed, 27 May 2009 17:47:13 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n4S0meW7027266 for ; Thu, 28 May 2009 09:48:40 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 18ee_4979e6c8_4b21_11de_9be5_001d0969ab06; Thu, 28 May 2009 09:48:40 +0900 Received: from [IPv6:::1] ([133.2.210.1]:46588) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 May 2009 09:45:40 +0900 Message-ID: <4A1DDEE3.1000309@it.aoyama.ac.jp> Date: Thu, 28 May 2009 09:46:27 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: John C Klensin Subject: Re: Structured data over TCP? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 00:47:16 -0000 It should be mentioned that although C (with string constants) and C's standard libraries do use a null byte delimiter to indicate string length, I think the general practice for 'fat' libraries and other languages implemented on top of C has been to use initial length indicators rather than null byte delimiters, for quite a long time. Initial length indicators are more efficient in many algorithms, for long strings, C's strlen() is quite inefficient. So it's less of a 'full circle' and more of a "we always have had both". But the advantages and disadvantages of these two techniques for internal processing and the advantages and disadvantages for data transfer are not exactly the same. I think a main reason why some main IETF protocols (e.g. HTTP) don't use initial length indicators is that these aren't suited for streaming, where you don't know how much data you're going to send when you start. If streaming isn't a concern for the data exchanges you are considering, then initial length indicators may be fine. Regards, Martin. On 2009/05/27 20:55, John C Klensin wrote: > Patrik, > > More on this when I've had time to study the Netstrings spec, > but a quick history review for those who may not remember... > > --On Wednesday, May 27, 2009 07:46 +0200 Patrik Fältström > wrote: > >> ... >> For those that do not know Netstrings, here is an example from >> the spec: >> >>> For example, the string "hello world!" is encoded as<31 32 >>> 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello >>> world!,". The empty string is encoded as "0:,". > > This is one of the oldest string formats around. Modulo the > fact that first-generation FORTRAN didn't have lower-case > characters, it would have been written as "12Hhello world!". > The machine-level coding of character strings on the > world-oriented machines of that generation would have been > > First word: 00...1100 (binary, left padded, e.g., 12) > Coded characters packed into as many subsequent words as > needed, with trailing padding. > > On the one character-oriented machine of that generation I > remember, strings were delimited by special "word marks"; I > can't remember whether the length was stored as well. > > In that generation, many of us learned that people really are > not good at counting characters, at least not if there are > significantly more than a half-dozen of them. That led in only > slightly later generations of languages to, e.g., 'hello world!' > with the compiler doing the counting as needed, but > length-string pairs remained the most common form until C became > prevalent. As you know, the DNS uses that form internally, so > it certainly isn't new to the Internet either. > > Coming full circle? > > john > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Wed May 27 18:17:06 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEF63A6E03 for ; Wed, 27 May 2009 18:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk11ujWBl2je for ; Wed, 27 May 2009 18:17:04 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 6676E3A71A2 for ; Wed, 27 May 2009 18:16:55 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n4S1Hxfr016363 for ; Thu, 28 May 2009 10:17:59 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 178f_767fd058_4b24_11de_aa3d_0019b9e2b3d9; Thu, 28 May 2009 10:11:24 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37287) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 May 2009 10:16:25 +0900 Message-ID: <4A1DE620.9080000@it.aoyama.ac.jp> Date: Thu, 28 May 2009 10:17:20 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: Structured data over TCP? References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4A1D8659.6010202@dcrocker.net> <7506B4121FEAC65A9A87FB97@PST.JCK.COM> <4A1DC581.6050108@dcrocker.net> In-Reply-To: <4A1DC581.6050108@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 01:17:06 -0000 On 2009/05/28 7:58, Dave CROCKER wrote: > John C Klensin wrote: >> It is perhaps not an accident that describes >> what is done with the DNS. > > DNS uses small, rather simple data objects. That makes the counts model > trivial. Also, DNS is extremely widely deployed, and extremely central to the operation of the Internet, that having double layers (a syntax for users/zone files/... and another on the wile), even if maybe it wasn't the best idea, has survived. I'm not sure that less important protocols with such a double layer would have that much success. In other words, I suspect that DNS is successful despite this double layer, not because of it. [The only positive reason I can see for the double layer is that DNS, much, much more than the higher-level data exchanges that we are discussing here, gains a lot from small data sizes that can be sent in a single packet over UDP.) > As for using different schemes between presentation versus transfer, that > invites translation errors. Besides that, the human-computer interface > of "display" and "input" are their own environments, not needing an > "exchange" encoding standard. If the suggestion is to map from user > input to some sort of parsed presentation-layer format and then map that > down to some sort of count-based transfer-layer format, I don't > understand the benefit. Again, it invites translation error, as well as > adding the overhead of the extra translation step. Agreed. > Ultimately, my own view about new meta-formats is that they need to > supply a compelling, practical value proposition. A number of existing > meta-formats have an enormous installed based of software and experience > and clearly function robustly and efficiently. I agree. Given the wide usage of Json in Ajax, I wouldn't call it a new format, although of course it's good to look at whether the advantages for Ajax translate into advantages in other usages. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From duerst@it.aoyama.ac.jp Wed May 27 18:24:50 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB733A688D for ; Wed, 27 May 2009 18:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X81DsyWhaDSI for ; Wed, 27 May 2009 18:24:50 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id C3A7F3A6452 for ; Wed, 27 May 2009 18:24:49 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n4S1QJI4017399 for ; Thu, 28 May 2009 10:26:19 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 0e24_8b931f98_4b26_11de_8cb3_001d0969ab06; Thu, 28 May 2009 10:26:19 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36245) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 28 May 2009 10:24:45 +0900 Message-ID: <4A1DE813.4040901@it.aoyama.ac.jp> Date: Thu, 28 May 2009 10:25:39 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Structured data over TCP? References: <4A1D0E50.1000006@it.aoyama.ac.jp> <5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se> <4D816A66-1BD7-4136-8DFE-EC94E1BD9178@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org, Andrew Newton X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 01:24:51 -0000 On 2009/05/28 2:44, Patrik Fältström wrote: > On 27 maj 2009, at 15.43, Andrew Newton wrote: > >>> That is why I propose the addition of netstring format for the >>> serialized JSON data. And that is why the XML blob in epp as a length >>> prefix. >> >> Just a guess here, but this is probably due to AJAX using HTTP and >> HTTPs content length header. > > I think so, but with XML you could also sort of "parse until you hit the > end tag", although I guess that is dangerous. Any XML parser essentially does that. I don't know of any XML parser which you can tell "Read that data stream, but only up to byte X". The question is how to integrate the XML parser with the layer that provides the length information. The easiest way is to read the length info, then read the rest of the data (up to that length) into a buffer of that length, then hand that buffer over to the XML parser. That works with smaller data, but not with really large data (what is small and what is large may vary depending on context). Parse until you hit the end tag isn't more dangerous with a correctly implemented XML parser than parsing a really, really long XML document; with both, you can run out of memory. With regards to the comma as a delimiter for netstring, I think selling it as a means to synchronize is a bad idea. If you care about security you don't want to synchronize, you want to stop processing. [One good thing about XML is that it is very clear that any kind of error is an error, and processing stops. Json may not be that clear.] Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From randy_presuhn@mindspring.com Wed May 27 22:11:32 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F453A6934 for ; Wed, 27 May 2009 22:11:32 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgBaYMOXQ7he for ; Wed, 27 May 2009 22:11:31 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 204403A68EC for ; Wed, 27 May 2009 22:11:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=klNRuX/ILlBRQFFRcw+eZ1Ofkbyqq1iqCv5yUaxYs/6lOnjUaDPilRqjDZ+r1SCC; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.137] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M9XvV-0007eE-Ox for apps-discuss@ietf.org; Thu, 28 May 2009 01:13:13 -0400 Message-ID: <002801c9df53$82b13160$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4A1D0E50.1000006@it.aoyama.ac.jp><5AC2CCD3-040C-4990-9CC0-8BAE0D2AE164@frobbit.se><4A1D8659.6010202@dcrocker.net><7506B4121FEAC65A9A87FB97@PST.JCK.COM> <4A1DC581.6050108@dcrocker.net> Subject: Re: Structured data over TCP? Date: Wed, 27 May 2009 22:16:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696854fe0d39e3e061607910b92e425c613f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.137 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 05:11:32 -0000 Hi - This is an aside to the real point of this thread.... > From: "Dave CROCKER" > To: > Sent: Wednesday, May 27, 2009 3:58 PM > Subject: Re: Structured data over TCP? ... > SNMP uses ASN.1, but that choice was forced onto the SNMP folks in a misguided > effort to make its data object compatible with CMIP and was complained about for > years by the SNMP folk. ... No, no, no. (1) The "compatibility" between SNMP and CMIP was never more than window dressing or propaganda. (I've implemented both.) The grammars of the two protocols are surprisingly different, as are the information models. One can kludge gateways, but the alleged compatibilities are of no help whatsoever in doing it. (2) The use of BER certainly was not an issue - there were no serious efforts to use some other encoding scheme when it came time to do SMP, or SNMPv2, or SNMPv2p, or SNMPv2*, or SNMPv2c, or SNMPv3. (3) SNMP's SMIv1 was a good demonstration of what ASN.1 didn't do well as a data modeling language, which was why SMIv2 (just like CMIP's GDMO) was *not* built on the ASN.1 language. But this was really independent of the use of (an adapted subset of) BER for the encoding. Randy From patrik@frobbit.se Thu May 28 02:01:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6740728C18E for ; Thu, 28 May 2009 02:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIF8yq9jevoS for ; Thu, 28 May 2009 02:01:32 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id D206B3A6842 for ; Thu, 28 May 2009 02:00:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id F064754BAB3A; Thu, 28 May 2009 11:02:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+zeAVDrBNyG; Thu, 28 May 2009 11:02:34 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 0401E54BAB33; Thu, 28 May 2009 11:02:34 +0200 (CEST) Message-Id: <0B7B1405-10A2-4401-8FA3-285E30F7F69E@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: =?ISO-8859-1?Q?=22Martin_J._D=FCrst=22?= In-Reply-To: <4A1DDEE3.1000309@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Thu, 28 May 2009 11:02:30 +0200 References: <4A1DDEE3.1000309@it.aoyama.ac.jp> X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 09:01:39 -0000 On 28 maj 2009, at 02.46, Martin J. D=FCrst wrote: > I think a main reason why some main IETF protocols (e.g. HTTP) don't =20= > use initial length indicators is that these aren't suited for =20 > streaming, where you don't know how much data you're going to send =20 > when you start. If streaming isn't a concern for the data exchanges =20= > you are considering, then initial length indicators may be fine. Agree, in many protocols you absolutely want to be able to start =20 sending data without buffering "the whole thing". Look at message/=20 partial content-type. When writing code that reads from a socket, I really enjoy knowing how =20= many bytes I have to read, so I can "just" ask the socket =20 implementation for that many bytes. And not write that parser that =20 read one byte at a time...phew...so netstring or epp-like length =20 prefixed things is something I like. Then, the reason I like JSON was simply the difference stated in the =20 excellent presentation by Tim, that XML has advantages (document-like =20= things, internationzation etc), but when "just" wanting structured =20 data "structs", and always use UTF-8, well...JSON is really really =20 nice. Maybe because I as a programmer much faster understood how the =20 JSON libraries work than XML libraries ;-) Yes, I talk one second on =20 implementation from scratch, and another about reusing libraries. Patrik From fanf2@hermes.cam.ac.uk Thu May 28 06:54:57 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7C03A6DBD for ; Thu, 28 May 2009 06:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0Db3cIyC+qq for ; Thu, 28 May 2009 06:54:55 -0700 (PDT) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id 89E5F3A6B73 for ; Thu, 28 May 2009 06:54:55 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37302) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1M9g5x-00034f-OY (Exim 4.70) (return-path ); Thu, 28 May 2009 14:56:33 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1M9g5x-0000Ed-JE (Exim 4.67) (return-path ); Thu, 28 May 2009 14:56:33 +0100 Date: Thu, 28 May 2009 14:56:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Structured data over TCP? In-Reply-To: <0B7B1405-10A2-4401-8FA3-285E30F7F69E@frobbit.se> Message-ID: References: <4A1DDEE3.1000309@it.aoyama.ac.jp> <0B7B1405-10A2-4401-8FA3-285E30F7F69E@frobbit.se> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1726407998-1243518993=:4749" Sender: Tony Finch Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 13:54:57 -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. --1870870024-1726407998-1243518993=:4749 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE > On 28 maj 2009, at 02.46, Martin J. D=FCrst wrote: > > > I think a main reason why some main IETF protocols (e.g. HTTP) don't us= e > > initial length indicators is that these aren't suited for streaming, wh= ere > > you don't know how much data you're going to send when you start. That's not a particularly good example. In most situations HTTP uses Content-Length for delimiting entity bodies using an initial count. It also supports a chunked Content-Transfer-Encoding for streaming purposes, where each chunk has an initial count. HTTP's original framing relied on closing the underlying connection, which isn't reliable. http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-o= r-why-is-my-tcp-not-reliable HTTP does not have any kind of delimiter-based framing. Dot stuffing as used in SMTP and NNTP is a better example. On Thu, 28 May 2009, Patrik F=E4ltstr=F6m wrote: > Agree, in many protocols you absolutely want to be able to start sending = data > without buffering "the whole thing". Look at message/partial content-type= =2E The message/partial content type is designed for getting large media through relays with low message size limits. It has nothing to do with streaming. Tony. --=20 f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. --1870870024-1726407998-1243518993=:4749-- From patrik@frobbit.se Thu May 28 07:07:01 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC13D3A6CFE for ; Thu, 28 May 2009 07:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52GQEe8HW8De for ; Thu, 28 May 2009 07:07:01 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 020913A6CCE for ; Thu, 28 May 2009 07:07:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 6369454CD078; Thu, 28 May 2009 16:08:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tsn89WkuQfi0; Thu, 28 May 2009 16:08:43 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id BA90754CD072; Thu, 28 May 2009 16:08:42 +0200 (CEST) Message-Id: <420634B2-105C-4A17-AEA2-A60E877169A9@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Tony Finch In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Thu, 28 May 2009 16:08:42 +0200 References: <4A1DDEE3.1000309@it.aoyama.ac.jp> <0B7B1405-10A2-4401-8FA3-285E30F7F69E@frobbit.se> X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 14:07:02 -0000 On 28 maj 2009, at 15.56, Tony Finch wrote: > On Thu, 28 May 2009, Patrik F=E4ltstr=F6m wrote: > >> Agree, in many protocols you absolutely want to be able to start =20 >> sending data >> without buffering "the whole thing". Look at message/partial =20 >> content-type. > > The message/partial content type is designed for getting large media > through relays with low message size limits. It has nothing to do with > streaming. I was thinking of the tagging of the message parts. Only the last part =20= have to have an indication of how many parts there are (total). You do =20= not have to know that when you receive data, start to split in pieces: > Three parameters must be specified in the Content-Type field of type > "message/partial": The first, "id", is a unique identifier, as close > to a world-unique identifier as possible, to be used to match the > fragments together. (In general, the identifier is essentially a > message-id; if placed in double quotes, it can be ANY message-id, in > accordance with the BNF for "parameter" given in RFC 2045.) The > second, "number", an integer, is the fragment number, which indicates > where this fragment fits into the sequence of fragments. The third, > "total", another integer, is the total number of fragments. This > third subfield is required on the final fragment, and is optional > (though encouraged) on the earlier fragments. Note also that these > parameters may be given in any order. Patrik From simon@josefsson.org Thu May 28 09:30:08 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66D928C291 for ; Thu, 28 May 2009 09:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SlIIrWXuNRB for ; Thu, 28 May 2009 09:30:07 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 18B5A28C2AC for ; Thu, 28 May 2009 09:30:06 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4SGVagB022789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 28 May 2009 18:31:38 +0200 X-Hashcash: 1:22:090528:apps-discuss@ietf.org::i07XAnCJQ/T/D72o:0Lth From: Simon Josefsson To: apps-discuss@ietf.org Subject: base encoding implementation report References: <20090528161501.D68173A6F20@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090528:internet-drafts@ietf.org::ps5oX5fqUFRlEQ0Q:QJeY X-Hashcash: 1:22:090528:i-d-announce@ietf.org::rXA/gGZNWBcXdTFn:QUVS Date: Thu, 28 May 2009 18:31:36 +0200 In-Reply-To: <20090528161501.D68173A6F20@core3.amsl.com> (Internet-Drafts@ietf.org's message of "Thu, 28 May 2009 09:15:01 -0700 (PDT)") Message-ID: <87skip5guv.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 16:30:09 -0000 All, I'm attempting to move RFC 4648 (on base64, base32, base16) to Draft Standard. Any thoughts on this? I started working on a implementation report, guided by Lisa and Robert's document. It surely needs work, but I'm unsure what improvements to make at this point. So I have posted a -00 document for review. If someone has implemented base encoding, especially the more exotic variants like base64url, base32 or base32hex, and wants to help testing, please contact me. I'm slightly concerned that the base64url alphabet may not be widely implemented. But it isn't clear to me that this would prevent the document from moving to Draft Status, confidence in interoperability can be inferred from the normal base64 alphabet. Any thoughts on this? Thanks, /Simon Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : RFC 4648 Implementation Report > Author(s) : S. Josefsson > Filename : draft-josefsson-rfc4648-impl-report-00.txt > Pages : 5 > Date : 2009-05-28 > > This is an implementation report of RFC4648, for the purpose of > advancing the document to Draft Standard. > See for more information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-rfc4648-impl-report-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > 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 vesely@tana.it Fri May 29 07:01:23 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48B73A6AED for ; Fri, 29 May 2009 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.824 X-Spam-Level: X-Spam-Status: No, score=0.824 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKDbJW8-yniF for ; Fri, 29 May 2009 07:01:22 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 773BA3A67D4 for ; Fri, 29 May 2009 07:01:22 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 29 May 2009 15:45:27 +0200 id 00000000005DC031.000000004A1FE6F7.000061B5 Message-ID: <4A1FE709.2070005@tana.it> Date: Fri, 29 May 2009 15:45:45 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: tbray@textuality.com Subject: Re: Structured data over TCP? References: <517bf110905270917m1032a9e2md146f4c88f2d6d8@mail.gmail.com> In-Reply-To: <517bf110905270917m1032a9e2md146f4c88f2d6d8@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 14:01:24 -0000 Tim Bray wrote: > I was going to start typing in a lengthy answer but then I remembered > I gave a tutorial at IETF70 on the choice of data formats for use in > Internet Protocols. It's centered around XML but I think covers many > of the other issues that have come up in this. Available for your > reading pleasure at http://www.tbray.org/tmp/IETF70.pdf That gives 404 Not Found. You probably meant http://www.ietf.org/proceedings/07dec/slides/xmltut-0.pdf Yes, it is centered on XML. May I ask why is JSON only suggested if "[t]he expected lifetime of the data is short"? Besides http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html also Google is apparently going to dismiss SOAP, as reported in http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/. Although there is a javascript library for SOAP in http://www.codeplex.com/JavaScriptSoapClient most javascript toolkits (see http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks) use JSON only. Does that tendency further decrease XML's attractiveness? Thanks for the tutorial Ale From Nicolas.Williams@sun.com Fri May 29 10:59:33 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1C43A6C4E for ; Fri, 29 May 2009 10:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW9SJS7egioX for ; Fri, 29 May 2009 10:59:31 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id B18893A6C47 for ; Fri, 29 May 2009 10:59:28 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4TI0P1C021081 for ; Fri, 29 May 2009 18:00:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4TI0OlN043213 for ; Fri, 29 May 2009 12:00:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4THoYUx015450; Fri, 29 May 2009 12:50:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4THoVNB015449; Fri, 29 May 2009 12:50:31 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 29 May 2009 12:50:31 -0500 From: Nicolas Williams To: Alessandro Vesely Subject: Re: Structured data over TCP? Message-ID: <20090529175030.GN29258@Sun.COM> References: <517bf110905270917m1032a9e2md146f4c88f2d6d8@mail.gmail.com> <4A1FE709.2070005@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1FE709.2070005@tana.it> User-Agent: Mutt/1.5.7i Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 17:59:33 -0000 On Fri, May 29, 2009 at 03:45:45PM +0200, Alessandro Vesely wrote: > Tim Bray wrote: > >I was going to start typing in a lengthy answer but then I remembered > >I gave a tutorial at IETF70 on the choice of data formats for use in > >Internet Protocols. It's centered around XML but I think covers many > >of the other issues that have come up in this. Available for your > >reading pleasure at http://www.tbray.org/tmp/IETF70.pdf > > Yes, it is centered on XML. May I ask why is JSON only suggested if > "[t]he expected lifetime of the data is short"? JSON assumes that the client and server agree on a schema. With XML the schema that the document complies with is referenced by the document itself. Therefore, if you have a volatile API then you need to have a way to do versioning if you use JSON. Then again, if you have data that has a long at-rest lifetime, then you really want to specify its schema somewhere, and once you're at that point you're better off with XML. Or at least I think that would be the argument. > Besides > http://nih.blogspot.com/2008/09/ive-been-asked-lot-about-use-of-soap-in.html > also Google is apparently going to dismiss SOAP, as reported in > http://blog.feedly.com/2009/03/03/jsonrest-vs-xmlsoap/. Although there > is a javascript library for SOAP in > http://www.codeplex.com/JavaScriptSoapClient most javascript toolkits > (see http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks) > use JSON only. Does that tendency further decrease XML's attractiveness? Just because SOAP uses XML doesn't mean that using XML implies using SOAP. There's now a JSON DOM, or work on it, which I expect will increase JSON's attractiveness. But in general I expect that _today_ JavaScript that edits the page's DOM will typically use XML documents retrieved with XMLHttpRequest for the simple reason that that's the simplest thing to do. A JSON DOM may change that, for all I know. Nico -- From timbray@gmail.com Fri May 29 11:37:36 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57753A6C1E for ; Fri, 29 May 2009 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XejKZPCWSWI0 for ; Fri, 29 May 2009 11:37:36 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 1C2993A6EBF for ; Fri, 29 May 2009 11:35:54 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so6269873ywj.49 for ; Fri, 29 May 2009 11:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QNADJTKQh82Mgdq17ddCYqvMw5bDnAxAOrDtEQ6kJfk=; b=ZBmGtQndoiVvu3hkM0dLiq+BfPChY0LlQCwm4One1Ce9W9VMS9804Z3Race4JNsgEP /04auY7QZib2kRwiSkqD3voJvvGiqaNGbILcA9m7O/5B7h5OC8VdQQmstPPMDlCs5Sr1 m5ZJ3tE0ZxVGKK36qqr1zjCE19nKfl9dZi2nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fWgvZXqetdywaW/3S2uZOXhp2xuXLEl9tXgR77QO38QyxbkSfdVbjrDjrnG27dhuIM Sp0N+iKfoRTxNtGww6kdkFyIqNw0DoplPt9GsTrel2D+yGUzwaR6IIzI0bvwpj4drvNz Cy5uNTfavb8t2J6EoQjy4K3xr7nnNQ36J6z/g= MIME-Version: 1.0 Sender: timbray@gmail.com Received: by 10.100.143.17 with SMTP id q17mr4064745and.114.1243621825246; Fri, 29 May 2009 11:30:25 -0700 (PDT) In-Reply-To: <20090529175030.GN29258@Sun.COM> References: <517bf110905270917m1032a9e2md146f4c88f2d6d8@mail.gmail.com> <4A1FE709.2070005@tana.it> <20090529175030.GN29258@Sun.COM> Date: Fri, 29 May 2009 11:30:25 -0700 X-Google-Sender-Auth: 2438afd395c004c4 Message-ID: <517bf110905291130i2d2522f9vabf5c48895d8c955@mail.gmail.com> Subject: Re: Structured data over TCP? From: Tim Bray To: Nicolas Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Alessandro Vesely X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 18:37:37 -0000 On Fri, May 29, 2009 at 10:50 AM, Nicolas Williams wrote: > JSON assumes that the client and server agree on a schema. =A0With XML th= e > schema that the document complies with is referenced by the document > itself. Neither of these assertions is correct. Good client and server designers will, where possible, try to decouple from the message details as much as possible. For example, in the case of JSON, send things as dicts and check to see whether the keys you need are there. And in the case of XML, the schema is not necessarily present, and including a pointer to one is considered bad practice by many including me, and furthermore, schema-based message validation at runtime is highly unusual. > Therefore, if you have a volatile API then you need to have a way to do > versioning if you use JSON. =A0Then again, if you have data that has a > long at-rest lifetime, then you really want to specify its schema > somewhere, and once you're at that point you're better off with XML. You need to have a way to version (or make an explicit choice not to) in any protocol-design exercise. It's not clear that XML-vs-JSON either helps or hurts. The argument for XML in the case of archival formats is that the label density is greater, so it's a bit more self-describing, so may preserve its usability longer. -Tim From vesely@tana.it Sat May 30 01:48:39 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB353A6F25 for ; Sat, 30 May 2009 01:48:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE+rlR++Jf74 for ; Sat, 30 May 2009 01:48:38 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 596543A6835 for ; Sat, 30 May 2009 01:48:38 -0700 (PDT) Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 30 May 2009 10:49:57 +0200 id 00000000005DC035.000000004A20F335.000015B9 Message-ID: <4A20F35D.1050905@tana.it> Date: Sat, 30 May 2009 10:50:37 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: tbray@textuality.com Subject: Re: Structured data over TCP? References: <517bf110905270917m1032a9e2md146f4c88f2d6d8@mail.gmail.com> <4A1FE709.2070005@tana.it> <20090529175030.GN29258@Sun.COM> <517bf110905291130i2d2522f9vabf5c48895d8c955@mail.gmail.com> In-Reply-To: <517bf110905291130i2d2522f9vabf5c48895d8c955@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Nicolas Williams X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 08:48:39 -0000 Tim Bray wrote: > On Fri, May 29, 2009 at 10:50 AM, Nicolas Williams > wrote: >> Therefore, if you have a volatile API then you need to have a way to do >> versioning if you use JSON. Then again, if you have data that has a >> long at-rest lifetime, then you really want to specify its schema >> somewhere, and once you're at that point you're better off with XML. In both cases one can learn the field names from a data snippet. Semantics, rules, constraints, and similar stuff, require a spec. > You need to have a way to version (or make an explicit choice not to) > in any protocol-design exercise. It's not clear that XML-vs-JSON > either helps or hurts. Versioning the data model may be loosely related with procedural requirements. Not that SOAP-vs-REST is a better conundrum... a framework might provide either web service transparently (e.g. that's what wso2 is apparently trying to achieve.) > The argument for XML in the case of archival formats is that the label > density is greater, so it's a bit more self-describing, so may > preserve its usability longer. However, the actual data on disk does not have to be laid down in the same format as the representation that is exchanged over TCP. An app may use the internal storage means it prefers, according to the amount of data and the read/write ratio. From phoffman@imc.org Sun May 31 18:24:26 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED623A6AF8 for ; Sun, 31 May 2009 18:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ah1061r70Za for ; Sun, 31 May 2009 18:24:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 11BE03A70DA for ; Sun, 31 May 2009 18:24:24 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n511OJZE064187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 31 May 2009 18:24:21 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 31 May 2009 18:24:16 -0700 To: apps-discuss@ietf.org From: Paul Hoffman Subject: Re: Structured data over TCP? Content-Type: text/plain; charset="us-ascii" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 01:24:26 -0000 At 12:50 PM -0500 5/29/09, Nicolas Williams wrote: >Therefore, if you have a volatile API then you need to have a way to do >versioning if you use JSON. Then again, if you have data that has a >long at-rest lifetime, then you really want to specify its schema >somewhere, and once you're at that point you're better off with XML. What is the problem with starting your JSON with a string that identifies the schema? { {"uid" : "97ad72a2"} { "count" : 42 } .... }. A parser can look for the first item in the structure and be sure that it exactly matches what it expects. From patrik@frobbit.se Sun May 31 23:36:19 2009 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7801D3A6C42 for ; Sun, 31 May 2009 23:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OU0ovAZGOvO for ; Sun, 31 May 2009 23:36:18 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 90AD93A6BB0 for ; Sun, 31 May 2009 23:36:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B63F655C667C; Mon, 1 Jun 2009 08:36:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl-nO67Qj6Eh; Mon, 1 Jun 2009 08:36:16 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 40E9655C6675; Mon, 1 Jun 2009 08:36:16 +0200 (CEST) Message-Id: <1C32C325-BCD4-4E70-BBC9-B161E0516382@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Structured data over TCP? Date: Mon, 1 Jun 2009 08:36:15 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 06:36:19 -0000 On 1 jun 2009, at 03.24, Paul Hoffman wrote: > At 12:50 PM -0500 5/29/09, Nicolas Williams wrote: >> Therefore, if you have a volatile API then you need to have a way >> to do >> versioning if you use JSON. Then again, if you have data that has a >> long at-rest lifetime, then you really want to specify its schema >> somewhere, and once you're at that point you're better off with XML. > > What is the problem with starting your JSON with a string that > identifies the schema? { {"uid" : "97ad72a2"} { "count" : > 42 } .... }. A parser can look for the first item in the structure > and be sure that it exactly matches what it expects. Even easier, you can have: { 'version' : 4711, 'data' : { 'foo' : 11, 'bar' : 'cookie' }} And then check for "version". And if "version" does not exist, bail. paf