From webdav-archive@ietf.org Mon Aug 2 07:01:20 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6533A6AFF for ; Mon, 2 Aug 2010 07:01:20 -0700 (PDT) X-Quarantine-ID: <9pUybfHM-2mF> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: webdav-archive@ietf.org Valium \256 Percocet 20% 0FF\n X-Spam-Flag: NO X-Spam-Score: -15.206 X-Spam-Level: X-Spam-Status: No, score=-15.206 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ANXIETY=0.01, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DRUG_GAP_VA=1.014, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 9pUybfHM-2mF for ; Mon, 2 Aug 2010 07:01:13 -0700 (PDT) Received: from spb-81-211-88-138.sovintel.spb.ru (spb-81-211-88-138.sovintel.spb.ru [81.211.88.138]) by core3.amsl.com (Postfix) with SMTP id BA7813A6B0E for ; Mon, 2 Aug 2010 07:01:12 -0700 (PDT) Message-ID: <20100802180136.2570.qmail@spb-81-211-88-138.sovintel.spb.ru> From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org Valium ® Percocet 20% 0FF MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Date: Mon, 2 Aug 2010 07:01:12 -0700 (PDT) http://kogtx.drawheart.ru?name=webdav-archive@ietf.org okratie plotzlich eine Majoritat zusammenbrauen lie.e, die — und ware es nur auf Grund ihrer zur Gesetzgebung berechtigten Mehrzahl — dem Marxismus ernstlich auf den Leib ruckte, so ware das parlamentarische Gaukelspiel gleich zu Ende. Die Bannertrager der roten Internationale wurden dann, statt einen Appell an das demokratische Gewissen zu richten, einen brandigen Aufruf an die proletarischen Massen erlassen, und ihr Kampf wurde sich mit einem Schlage aus der muffigen Luft der Sitzungssale unserer Parlamente in die Fabriken und auf die Stra.e verpflanzen. Die Demokratie ware damit sofort erledigt; und was der geistigen Gelenkigkeit jener Volkerapostel in den Parlamenten From liqoyerap6749@comcast.net Thu Aug 5 02:34:06 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12FA3A6B0E for ; Thu, 5 Aug 2010 02:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.741 X-Spam-Level: X-Spam-Status: No, score=-65.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_SBL=20, 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 sHN-obSmLjqW for ; Thu, 5 Aug 2010 02:33:24 -0700 (PDT) Received: from comcast.net (c-76-22-140-60.hsd1.ky.comcast.net [76.22.140.60]) by core3.amsl.com (Postfix) with ESMTP id 5BC063A6846 for ; Thu, 5 Aug 2010 02:30:35 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Thu, 5 Aug 2010 04:29:34 -0500 Subject: Your ego is boosted instantly Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100805093049.5BC063A6846@core3.amsl.com> All men want this, and all women love this – click here to find out. http://www.avatarfish.ru/ From webdav-archive@ietf.org Thu Aug 5 04:43:44 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A6F3A6AEE for ; Thu, 5 Aug 2010 04:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.711 X-Spam-Level: X-Spam-Status: No, score=-86.711 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_34=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 EK94kLP9fI6Y for ; Thu, 5 Aug 2010 04:43:40 -0700 (PDT) Received: from triband-mum-120.60.147.247.mtnl.net.in (triband-mum-120.60.137.224.mtnl.net.in [120.60.137.224]) by core3.amsl.com (Postfix) with SMTP id A52D93A686B for ; Thu, 5 Aug 2010 04:43:39 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org 42% OFF on Pfizer! MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100805114339.A52D93A686B@core3.amsl.com> Date: Thu, 5 Aug 2010 04:43:39 -0700 (PDT) http://groups.yahoo.com/group/moursebashirvv/message wandelt, es war finster um mich geworden. geworden. Es lag etwas Unbestimmtes, aber Widerliches schon lange in der Luft. Man erzahlte sich, da. es in den nachsten Wochen "los"gehe — ich vermochte mir nur nicht vorzustellen, was darunter zu verstehen sei. Ich dachte in erster Linie an einen Streik, ahnlich dem des Fruhjahrs. Ungunstige Geruchte kamen dauernd aus der Marine, in der es garen sollte. Allein auch dieses schien mir mehr die Ausgeburt der Phantasie einzelner Burschen als Angelegenheit gro.erer Massen zu sein. Im Lazarett selbst redete wohl jeder von der From yfosa2586@comcast.net Sat Aug 7 03:10:12 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B593A694D for ; Sat, 7 Aug 2010 03:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.741 X-Spam-Level: X-Spam-Status: No, score=-15.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 VlsSuldvugeg for ; Sat, 7 Aug 2010 03:10:10 -0700 (PDT) Received: from comcast.net (c-68-55-148-76.hsd1.md.comcast.net [68.55.148.76]) by core3.amsl.com (Postfix) with ESMTP id 939B73A68EF for ; Sat, 7 Aug 2010 03:10:08 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Sat, 7 Aug 2010 06:10:47 -0400 Subject: 10 ways to make her moan in ecstasy Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100807101008.939B73A68EF@core3.amsl.com> Show your hot date a sizzling time in the sack. http://www.dirtywine.ru/ From webdav-archive@ietf.org Sat Aug 7 07:07:33 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D8C3A6947 for ; Sat, 7 Aug 2010 07:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.896 X-Spam-Level: X-Spam-Status: No, score=-81.896 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_24=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 J1nfkOm76O7g for ; Sat, 7 Aug 2010 07:07:32 -0700 (PDT) Received: from dynamic.rabat2-104-236-12-196.wanamaroc.com (dynamic.rabat2-4-236-12-196.wanamaroc.com [196.12.236.4]) by core3.amsl.com (Postfix) with SMTP id 398FD3A6858 for ; Sat, 7 Aug 2010 07:07:30 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org 29% OFF on Pfizer! MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100807140731.398FD3A6858@core3.amsl.com> Date: Sat, 7 Aug 2010 07:07:30 -0700 (PDT) http://groups.yahoo.com/group/rimingtoungallono/message dete dort seinen eigenen Staat, der allerdings so lange unter der Bezeichnung "Religionsgemeinschaft" maskiert zu segeln pflegte, als die au.eren Umstande kein vollstandiges Enthullen seines Wesens angezeigt sein lie.en. Glaubte er sich aber einmal stark genug, um der Schutzdecke entbehren zu konnen, dann lie. er noch immer den Schleier fallen und war plotzlich das, was so viele andere fruher nicht glauben und sehen wollten: der Jude. Im Leben des Juden als Parasit im Korper anderer Nationen und Staaten liegt eine Eigenart begrundet, die {335 Judische "Reli From amyoyh6624@comcast.net Sat Aug 7 14:09:51 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA9F3A6A07 for ; Sat, 7 Aug 2010 14:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.86 X-Spam-Level: X-Spam-Status: No, score=-68.86 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_SBL=20, 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 Mo8sbaNfHKi3 for ; Sat, 7 Aug 2010 14:09:50 -0700 (PDT) Received: from comcast.net (c-76-23-182-255.hsd1.ny.comcast.net [76.23.182.255]) by core3.amsl.com (Postfix) with ESMTP id A90B63A6A01 for ; Sat, 7 Aug 2010 14:09:50 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Sat, 7 Aug 2010 17:10:30 -0400 Subject: You can be the Alpha Male Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100807210950.A90B63A6A01@core3.amsl.com> Yesterday when I took Christina in the living room, she kept coming and coming. http://www.rhythmform.ru/ From ygonu2022@comcast.net Mon Aug 9 12:19:29 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5193A69C0 for ; Mon, 9 Aug 2010 12:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.026 X-Spam-Level: X-Spam-Status: No, score=-46.026 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, 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 6nQ5zLz2r0iH for ; Mon, 9 Aug 2010 12:19:28 -0700 (PDT) Received: from comcast.net (c-69-181-63-48.hsd1.ca.comcast.net [69.181.63.48]) by core3.amsl.com (Postfix) with ESMTP id DA6B83A6841 for ; Mon, 9 Aug 2010 12:19:28 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Mon, 9 Aug 2010 12:20:19 -0700 Subject: Tremendous growth guaranteed Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100809191928.DA6B83A6841@core3.amsl.com> Have a 8 inch pecker gets you the ladies far easier than a ferrari will. http://www.soundfixed.ru/ From tyyovypi5175@comcast.net Mon Aug 9 15:56:31 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD563A6878 for ; Mon, 9 Aug 2010 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.741 X-Spam-Level: X-Spam-Status: No, score=-65.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_SBL=20, 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 ZXb2esCe3c6h for ; Mon, 9 Aug 2010 15:56:30 -0700 (PDT) Received: from comcast.net (c-76-23-184-245.hsd1.ct.comcast.net [76.23.184.245]) by core3.amsl.com (Postfix) with ESMTP id 1D1673A697F for ; Mon, 9 Aug 2010 15:56:29 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Mon, 9 Aug 2010 18:56:56 -0400 Subject: Revealed - Brad pitt's wonderful tricks Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100809225630.1D1673A697F@core3.amsl.com> No tricks, no catch - get 3-6 inches of guaranteed growth here now http://www.mountaindesign.ru/ From ieluveoug8264@comcast.net Mon Aug 9 17:33:44 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DBC3A68B2 for ; Mon, 9 Aug 2010 17:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.741 X-Spam-Level: X-Spam-Status: No, score=-65.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_SBL=20, 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 QRahny1HnQ6O for ; Mon, 9 Aug 2010 17:33:42 -0700 (PDT) Received: from comcast.net (c-68-84-223-210.hsd1.pa.comcast.net [68.84.223.210]) by core3.amsl.com (Postfix) with ESMTP id 749D93A6881 for ; Mon, 9 Aug 2010 17:33:42 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Mon, 9 Aug 2010 20:34:18 -0400 Subject: Topless pics of Hollywood stars Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100810003342.749D93A6881@core3.amsl.com> Get significantly better lovemaking fun here now http://www.antbeach.ru/ From loheqof1643@comcast.net Tue Aug 10 15:55:44 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AAF3A68A7 for ; Tue, 10 Aug 2010 15:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.026 X-Spam-Level: X-Spam-Status: No, score=-46.026 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, 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 Ov2UTASK5sbQ for ; Tue, 10 Aug 2010 15:55:43 -0700 (PDT) Received: from comcast.net (c-69-250-122-196.hsd1.md.comcast.net [69.250.122.196]) by core3.amsl.com (Postfix) with ESMTP id 3469C3A6842 for ; Tue, 10 Aug 2010 15:55:43 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Tue, 10 Aug 2010 18:56:17 -0400 Subject: Massive 9 inches Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100810225543.3469C3A6842@core3.amsl.com> Give her the most pleasure you can http://www.clockbank.ru/ From uopio3538@comcast.net Wed Aug 11 22:46:41 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40D23A695A for ; Wed, 11 Aug 2010 22:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.026 X-Spam-Level: X-Spam-Status: No, score=-46.026 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, 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 vUPsPqsGfd10 for ; Wed, 11 Aug 2010 22:46:41 -0700 (PDT) Received: from comcast.net (c-67-174-52-211.hsd1.ca.comcast.net [67.174.52.211]) by core3.amsl.com (Postfix) with ESMTP id 18D463A6988 for ; Wed, 11 Aug 2010 22:46:41 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Wed, 11 Aug 2010 22:47:19 -0700 Subject: Why girls like it harder Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100812054641.18D463A6988@core3.amsl.com> Willie Wanker and the fudge packing factory http://www.importancedeal.ru/ Operation Bringing Home the Goods. Pirouettes can be executed with a single or multiple rotations. Emphasis on gameplay turned comparatively simple games into unlikely runaway hits, including the bundled game, Wii Sports, and Wii Fit. The programmable automata of al-Jazari. The Trenton Line terminates at the Trenton Transit Center, and the West Trenton Line terminates at the West Trenton Rail Station in Ewing. Integrated Regional Information Networks (IRIN). The highlight was a 2-1 win away at Manchester City, where first half goals from Baird and Devine sealed a magnificent double against the fallen giants. Pakistan Railways Boy Scouts Association. From w3c-dist-auth-request@listhub.w3.org Thu Aug 12 01:38:48 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AF528C0F6 for ; Thu, 12 Aug 2010 01:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=2.084, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 DowJwxaMbAj6 for ; Thu, 12 Aug 2010 01:38:46 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 948183A696B for ; Thu, 12 Aug 2010 01:38:46 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OjTIF-0006tG-O1 for w3c-dist-auth-dist@listhub.w3.org; Thu, 12 Aug 2010 08:37:43 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OjTIE-0006rG-Q1 for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2010 08:37:42 +0000 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OjTIC-0001va-NA for w3c-dist-auth@w3.org; Thu, 12 Aug 2010 08:37:42 +0000 Received: (qmail invoked by alias); 12 Aug 2010 08:37:07 -0000 Received: from p508FE608.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.230.8] by mail.gmx.net (mp013) with SMTP; 12 Aug 2010 10:37:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18jGnYFbvQjoiMUD9ZxgDC0RIBVoJ8MZlxRMPrltU oZ8hNYp0eDlIFx Message-ID: <4C63B2AB.6090701@gmx.de> Date: Thu, 12 Aug 2010 10:36:59 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: WebDAV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OjTIC-0001va-NA 0d993aaf03ce9de447b2bbcd336bed42 X-Original-To: w3c-dist-auth@w3.org Subject: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13293 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 12 Aug 2010 08:37:43 +0000 Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange HTTP/1.1 (RFC 2616) already contains a set of tools for modifying resources , namely the methods PUT, POST, and DELETE. Many systems have been built on top of this, most of them in an ad-hoc manner (which is ok when client and server are controlled by the same developers). We would like to cover some of the following use cases extending the resource oriented model. (1) An simple javascript based browser application should be able to read fine-grained information (comparable to WebDAV properties) in a simple manner using a defined JSON format to be consumed in an intuitive fashion. (2) A simple HTML Form should be able to write information in a patch oriented manner containing both binary (file) data and fine-grained, typed information using a multipart POST. (3) A simple javascript application should be able to write information in a patch oriented fashion using a defined JSON-diff PATCH content-type to update fine-grained information. There are also several extensions/applications of HTTP in this space, such as: - WebDAV (RFC 4918), which defines (a) a collection model and methods to manipulate collections/namespaces, (b) a metadata (=property) model, and (c) locking. Other RFCs add extensions on top of this, such as Versioning (RFC 3253) and ACLs (RFC 3744). - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler, not necessarily hierarchic collection model (which, depending on the use case, may be a plus), but does not provide many features WebDAV + friends define. Notably, namespace operations are absent. WebDAV and AtomPub have been very successful so far. WebDAV gets used both as a plain remote filesystem protocol (as observed by clients being shipped with all operating systems, and both Apache httpd and IIS supporting it), and for specific applications, such as Versioning (subversion), Calendaring (CalDAV), etc. The same is true for AtomPub, which actually may not be used a lot in practice for the original use case (feed authoring), but for many other things instead. Both of those protocol specifications are not easily consumed by websites and applications running current browsers and require a lot of client-sided scripting to cover simple read and write use cases. There's a proposal for a protocol called "JSOP", which addresses these use cases, which we may want to consider as input for this work: So what's wrong with WebDAV? Since the time WebDAV was designed, we have learned a lot how to use the Web and HTTP. Such as: - if you want to expose data for read operations, make it available to GET, and assign URIs, - consider cacheability, atomicity, and performance of sync operations (for instance, syncing large collections), - be careful with new HTTP methods -- avoid them for things that are not of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that certain platforms (HTML forms, Flash...) can't use them, - when defining formats, also define internet media types. Also, in the last few months, new (and not so new) techniques have finally been published as RFCs, such as: - HTTP PATCH method (RFC 5789) - HTTP Link Header and Link Relations Registry (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in the RFC Editor queue) - Service Discovery through well-known URIs (RFC 5785) Another potential building block are URI templates (work in progress: http://tools.ietf.org/html/draft-gregorio-uritemplate-04) Considering all of these pieces, it's quite obvious that there's a number of specs that would be useful on their own, but could also, combined together, form the basis of an interesting authoring protocol: # Data Model 1) Define a collection model (hierarchy, naming), and a representation format. Can we re-use the WebDAV collection model here? Web application authors probably would prefer a JSON representation, so can we simply define this as an alternate representation of a DAV:multistatus description of a collection? 2) Define namespace operations in terms of manipulating collection representations (also consider a mapping to COPY/MOVE). 3) Define a media type to use with PATCH for modifying these representations. 4) Define a property model (something like the intersection between WebDAV properties and Java Content Repository (JSR-283) properties?) # Authoring through HTML forms and POST Define how POST with multipart/form-data (RFC 2388) can be used for authoring both content and properties. # URIs for collection browsing Assign either hardwired or discoverable URIs for inspecting collections (URI templates?). Or maybe link relations for collection navigation (similar work for versioning: RFC 5829). # Improvements to WebDAV 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this question comes up quite frequently). 2) Define how to use POST on WebDAV collections to add members (done: see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC Editor queue). 3) Define media types (multiple?) for DAV:multistatus. 4) Define a discovery mechanism for GETtable representations of PROPFIND/REPORT results (old proposal: http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html). 5) Define a mapping between link-typed WebDAV properties and generic Link relations (see proposal: http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). Although some of this will only be partially related to WebDAV, we think that this mailing list might be a good venue for discussion. Expected deliverables from this activity would be: 1) Definition of a very simply data model and a representation format for it (required JSON, optionally XML). 2) A format suitable for manipulating the data format above using PATCH (potentially tunneled through POST). 3) A binding from multipart/form-data/POST to this model. 4) A separate (?) document explaining how these ingredients would be combined in practice. Extensions to WebDAV and mappings from/to WebDAV could be useful, but would not be a core part of this activity. (That is, we can do without if no volunteers speak up). Note that not all of these specs necessarily need to be on the standards track; for instance, there might be candidates for Informational RFCs as well (see for details). Feedback appreciated. Julian Reschke David Nüscheler PS: people not familiar with the IETF may want to have a look at From webdav-archive@ietf.org Thu Aug 12 03:54:53 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0683A6832 for ; Thu, 12 Aug 2010 03:54:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -17.914 X-Spam-Level: X-Spam-Status: No, score=-17.914 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FB_GET_MEDS=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 oXLoPAOKkwtb for ; Thu, 12 Aug 2010 03:54:47 -0700 (PDT) Received: from 78-25-43-220.static.vega-ua.net (78-25-43-220.static.vega-ua.net [78.25.43.220]) by core3.amsl.com (Postfix) with SMTP id 7F4943A6855 for ; Thu, 12 Aug 2010 03:54:46 -0700 (PDT) Message-Id: <20100812135929.2609.qmail@78-25-43-220.static.vega-ua.net> To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org VIAGRA ® Official Seller -04% From: webdav-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 12 Aug 2010 03:54:46 -0700 (PDT) Dear webdav-archive@ietf.org Get ready to make her happy. Discount price store: ID69089797 http://smilehe.ru We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From iwacyc4731@force9.co.uk Thu Aug 12 04:29:44 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57D03A6866 for ; Thu, 12 Aug 2010 04:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.549 X-Spam-Level: *** X-Spam-Status: No, score=3.549 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_UNI=0.591] 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 I-9WYL0YPgjj for ; Thu, 12 Aug 2010 04:29:43 -0700 (PDT) Received: from force9.co.uk (stanleyyule1.force9.co.uk [84.92.201.94]) by core3.amsl.com (Postfix) with ESMTP id 24FD43A6857 for ; Thu, 12 Aug 2010 04:29:42 -0700 (PDT) From: Top drugstore of male cures To: webdav-archive@ietf.org Subject: User webdav-archive, discount time begins. and an own is Date: Thu, 12 Aug 2010 12:21:32 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100812112943.24FD43A6857@core3.amsl.com> likes same glaciers in Newsletter
If you are unable to see the message below, click here to view.

Pillsstore's link

At this time both the kings
of Sweden and of Denmark were elected to the throne by their respective nobles. According to the Constitution of Norway, which was adopted on 17 May 1814 and inspired by the United States Declaration of Independence and French Revolution of 1776 and 1798, respectively, Norway is a unitary constitutional monarchy with a parliamentary system of government, wherein the King of Norway is the head of state and the Prime Minister is the head of government. Berg was a regular choice in the United line-up in season 1997-98. Thus, upon his ascension to the throne of Norway, Olaf united Denmark and Norway under a single throne.The towns of Biarritz, Anglet, and Bayonne are originally Occitan-speaking, with Basque-speaking groups, but their Basque populations grew sharply during the industrial revolution.A comparison of the lexical content can find more subtle differences between the languages. Poza quotes the Basques inhabiting lands as far east as the River Gallego in the 16th century. There was no strong bourgeosie class in Norway to demand a breakdown of this aristocratic control of the economy. First Mutual Evaluation Report on the Principality of Monaco, Moneyval, Strasbourg,

2003. French

is the dominant language. Sometimes, there is some conflict between
some users of
each system. Sami population is not clearly defined, but is believed to amount from 60,000 to 100,000 persons, or 1. Upon the death of Haakon VI, in 1379, his son, Olaf IV was only 10 years-old. There are approximately 60,000 species in Norway and adjacent waters (excluding bacteria and virus). Former municipality of La Condamine.Berg was a regular choice in the United line-up in season 1997-98. The southern and western parts of Norway experience more precipitation and have milder winters than the southeastern part.The movie became the highest grossing Norwegian movie ever. Monaco has also competed in the Olympic Games, although, as of 2008, no athlete from Monaco has ever won an Olympic medal. A comparison of the lexical content can find more subtle differences between the languages. The lo-fi, dark and raw form of heavy metal exploded in Norway during the 90s and launched the worldwide acclaimed careers of bands such as Gorgoroth, Mayhem, Burzum, Emperor, Darkthrone and Immortal, as well as later bands such as Dimmu Borgir.This period also saw the rise of the Norwegian romantic nationalism, as Norwegians
sought
to define and express a distinct national character. Besides enacting parliamentary bills, all government bills need the formal approval by the Monarch before and after introduction to Parliament. Henning Berg career stats at Soccerbase.Sarajevo, Bosnia and Herzegovina. A comparison of terms and word counts between languages is not easy, as it is impossible to precisely count the number of words in a language.Karen Larsen, A History of Norway p. Occitania, the territory of the Occitan language. Comparison with other Romance languages. Several Finno-Ugric Sami languages are spoken and written throughout the country, especially in the north, by the Sami people. See Lexicon, Lexeme, Lexicography for more information. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood. Indeed the Thrane movement was the only "revolt" that broke out in Norway in 1848. Poza quotes the Basques inhabiting lands as far east as the River Gallego in the 16th century. To the north, however, its territory was increased by the acquisition of the northern provinces of Troms and Finnmark, at the expense of Sweden and Russia.The Lengadocian dialect, excepting the Southern Lengadocian subdialect.

© 2009 in to more Inc. All rights reserved.

Unsubscribe

From webdav-archive@ietf.org Thu Aug 12 15:20:50 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6C13A69CC for ; Thu, 12 Aug 2010 15:20:49 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -20.435 X-Spam-Level: X-Spam-Status: No, score=-20.435 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FB_GET_MEDS=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, MIME_8BIT_HEADER=0.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 PU114o6OuOJk for ; Thu, 12 Aug 2010 15:20:42 -0700 (PDT) Received: from 201-24-16-44.gnace701.dsl.brasiltelecom.net.br (201-24-16-44.gnace701.dsl.brasiltelecom.net.br [201.24.16.44]) by core3.amsl.com (Postfix) with SMTP id 0AEAE3A694E for ; Thu, 12 Aug 2010 15:20:36 -0700 (PDT) Message-Id: <20100812192013.2298.qmail@201-24-16-44.gnace701.dsl.brasiltelecom.net.br> To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org VIAGRA ® Official Seller -15% From: webdav-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 12 Aug 2010 15:20:36 -0700 (PDT) Dear webdav-archive@ietf.org Get ready to make her happy. Discount price store: ID69851 http://mixnorth.ru We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From ypuiguvuny2054@comcast.net Thu Aug 12 15:47:00 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E754A3A6A5A for ; Thu, 12 Aug 2010 15:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.36 X-Spam-Level: X-Spam-Status: No, score=-46.36 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, 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 vGCI1rpWynoE for ; Thu, 12 Aug 2010 15:46:58 -0700 (PDT) Received: from comcast.net (c-24-98-212-132.hsd1.ga.comcast.net [24.98.212.132]) by core3.amsl.com (Postfix) with ESMTP id 251FC3A6A43 for ; Thu, 12 Aug 2010 15:46:58 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Thu, 12 Aug 2010 18:47:25 -0400 Subject: Feels great having a heavy wang Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100812224658.251FC3A6A43@core3.amsl.com> Be as large as you want with new improved herbal formulas http://www.mobmetal.ru/ China has an estimated 926,000researchers, second only to the 1. Fluellen Theatre Company is a professional theatre company based in Swansea performing regularly at the Grand Theatre. Energy Statistics for Russia from the Energy Information Administration. Proposals from Plymouth for a Tamarside county were rejected. This has led to the shipping industry losing confidence in the classification societies, and also to similar concerns by the European Commission. Farbas were picked by the mansa from the conquering farin, family members or even slaves. Relationship with traditional music. A b "The Business Competitiveness Index (BCI) ranking". From w3c-dist-auth-request@listhub.w3.org Fri Aug 13 01:37:01 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17A73A68C8 for ; Fri, 13 Aug 2010 01:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.234 X-Spam-Level: X-Spam-Status: No, score=-7.234 tagged_above=-999 required=5 tests=[AWL=3.365, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 IARA1Rf0yV-a for ; Fri, 13 Aug 2010 01:37:00 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 8663A3A6830 for ; Fri, 13 Aug 2010 01:37:00 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OjpkJ-0000xA-2G for w3c-dist-auth-dist@listhub.w3.org; Fri, 13 Aug 2010 08:36:11 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OjpkI-0000vX-2c for w3c-dist-auth@listhub.w3.org; Fri, 13 Aug 2010 08:36:10 +0000 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OjpkF-00047b-Jy for w3c-dist-auth@w3.org; Fri, 13 Aug 2010 08:36:10 +0000 Received: (qmail invoked by alias); 13 Aug 2010 08:35:35 -0000 Received: from p508FDA39.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.218.57] by mail.gmx.net (mp047) with SMTP; 13 Aug 2010 10:35:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188nYZX4sI8OaWfYTEKbK+8cug8EmR+LCYPKZD6RM FLm86nroB7o2M5 Message-ID: <4C6503CD.7080807@gmx.de> Date: Fri, 13 Aug 2010 10:35:25 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: WebDAV References: <4C63B2AB.6090701@gmx.de> In-Reply-To: <4C63B2AB.6090701@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1OjpkF-00047b-Jy 8bea9ad89e4d2acbf5157b7ef305732e X-Original-To: w3c-dist-auth@w3.org Subject: Webdav related extensions, was: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13294 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 13 Aug 2010 08:36:11 +0000 On 12.08.2010 10:36, Julian Reschke wrote: > # Improvements to WebDAV > > 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this > question comes up quite frequently). > > 2) Define how to use POST on WebDAV collections to add members (done: > see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC > Editor queue). > > 3) Define media types (multiple?) for DAV:multistatus. > > 4) Define a discovery mechanism for GETtable representations of > PROPFIND/REPORT results (old proposal: > http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html). > > > 5) Define a mapping between link-typed WebDAV properties and generic > Link relations (see proposal: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). > ... 6) A media type for PATCH that allows setting WebDAV properties and the content in a single request (PUT/PROPPATCH combined). Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Fri Aug 13 10:46:33 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730F63A6902 for ; Fri, 13 Aug 2010 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Xbi0Ba3HrmO8 for ; Fri, 13 Aug 2010 10:46:29 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 347C63A635F for ; Fri, 13 Aug 2010 10:46:29 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OjyJy-0003Zu-Gs for w3c-dist-auth-dist@listhub.w3.org; Fri, 13 Aug 2010 17:45:34 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OjyJx-0003YW-LD for w3c-dist-auth@listhub.w3.org; Fri, 13 Aug 2010 17:45:33 +0000 Received: from wvmler1.mail.xerox.com ([13.8.138.216]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OjyJu-0004No-5W for w3c-dist-auth@w3.org; Fri, 13 Aug 2010 17:45:32 +0000 Received: from wvmlir2.mail.xerox.com (wvmlir2.mail.xerox.com [13.147.8.222]) by wvmler1.mail.xerox.com (8.14.4/8.13.8) with ESMTP id o7DHivw2029371; Fri, 13 Aug 2010 10:44:57 -0700 Received: from wvmlir2.mail.xerox.com (localhost [127.0.0.1]) by wvmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o7DHijd4025883; Fri, 13 Aug 2010 10:44:45 -0700 Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.101.10]) by wvmlir2.mail.xerox.com (8.14.4/8.13.6) with ESMTP id o7DHijnx025870; Fri, 13 Aug 2010 10:44:45 -0700 X-XeroxINT-Source-Ip: 13.242.101.10 X-XeroxINT-Source-Name: godzilla.ADOC.xerox.com X-XeroxINT-Reported-Name: godzilla.ADOC.xerox.com Received: from [13.242.104.145] (klotzpc.ADOC.xerox.com [13.242.104.145]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id KAA00599; Fri, 13 Aug 2010 10:44:44 -0700 (PDT) Message-ID: <4C65848C.50504@xerox.com> Date: Fri, 13 Aug 2010 10:44:44 -0700 From: "Leigh L. Klotz, Jr" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: Julian Reschke References: <4C63C3DA.50809@gmx.de> In-Reply-To: <4C63C3DA.50809@gmx.de> Content-Type: multipart/alternative; boundary="------------010400060507060605090801" Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: lisa.w3.org 1OjyJu-0004No-5W f67ac39c4b133cd4de660ca193c9e945 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fwd: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13295 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 13 Aug 2010 17:45:34 +0000 This is a multi-part message in MIME format. --------------010400060507060605090801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by wvmler1.mail.xerox.com id o7DHivw2029371 [re-post from atom-protocol@mic.org at Julian's request] You might consider looking at multipart/related POST of XML (or JSON)=20 and document content data. An XForms binding would also be a good match, since XForms is designed=20 to be a REST client, and it has good support for structured XML data=20 such as Atom, and for POST and PUT of multipart/related data. XForms already has a high adoption rate in the CMS / ECM industry=20 already (our own product DocuShare, Documentum/EMC, Alfresco, Atlassian,=20 Nuxeo, SmartSite iXperion, MarkLogic, etc.) There are good, free JavaScript implementations of XForms (Ubiquity=20 XForms from IBM et al, XSLTForms from AgenceXML) and free server-side=20 ones as well (Orbeon, Betterforms, etc.). Not all of these free implementations support multipart/related POST of=20 XML with attached documents, but until browser support for MVC=20 frameworks gets better, you can define an alternate wire syntax using=20 multipart/form-data with one field containing a string of XML. A=20 similar approach has been used in old implementations of JavaScript's=20 XHR which don't support DELETE and PUT, by setting a well-known header=20 to communicate the real intent and using POST. Leigh Klotz Xerox Corp. On 08/12/2010 02:50 AM, Julian Reschke wrote: > > FYI - a proposal for collaboration on an authoring protocol that would > be more browser-friendly than WebDAV or AtomPub -- for now we started > discussion on the IETF WebDAV mailing list (hosted by the W3C). > > Feedback appreciated. > > -------- Original Message -------- > Subject: Proposal for work on an efficient, browser-friendly, HTTP-base= d > communication protocol for fine-grained information exchange > Date: Thu, 12 Aug 2010 10:36:59 +0200 > From: Julian Reschke > To: WebDAV > > Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange > > HTTP/1.1 (RFC 2616) already contains a set of tools for modifying > resources , namely the methods PUT, POST, and DELETE. > > Many systems have been built on top of this, most of them in an ad-hoc > manner (which is ok when client and server are controlled by the same > developers). > > We would like to cover some of the following use cases extending the > resource oriented model. > > (1) An simple javascript based browser application should be able to > read fine-grained information (comparable to WebDAV properties) in a > simple manner using a defined JSON format to be consumed in an intuitiv= e > fashion. > > (2) A simple HTML Form should be able to write information in a patch > oriented manner containing both binary (file) data and fine-grained, > typed information using a multipart POST. > > (3) A simple javascript application should be able to write information > in a patch oriented fashion using a defined JSON-diff PATCH content-typ= e > to update fine-grained information. > > There are also several extensions/applications of HTTP in this space, > such as: > > - WebDAV (RFC 4918), which defines (a) a collection model and methods t= o > manipulate collections/namespaces, (b) a metadata (=3Dproperty) model, = and > (c) locking. Other RFCs add extensions on top of this, such as > Versioning (RFC 3253) and ACLs (RFC 3744). > > - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler, > not necessarily hierarchic collection model (which, depending on the us= e > case, may be a plus), but does not provide many features WebDAV + > friends define. Notably, namespace operations are absent. > > WebDAV and AtomPub have been very successful so far. WebDAV gets used > both as a plain remote filesystem protocol (as observed by clients bein= g > shipped with all operating systems, and both Apache httpd and IIS > supporting it), and for specific applications, such as Versioning > (subversion), Calendaring (CalDAV), etc. The same is true for AtomPub, > which actually may not be used a lot in practice for the original use > case (feed authoring), but for many other things instead. > > Both of those protocol specifications are not easily consumed by > websites and applications running current browsers and require a lot of > client-sided scripting to cover simple read and write use cases. > > There's a proposal for a protocol called "JSOP", which addresses these > use cases, which we may want to consider as input for this work: > > > So what's wrong with WebDAV? > > Since the time WebDAV was designed, we have learned a lot how to use th= e > Web and HTTP. Such as: > > - if you want to expose data for read operations, make it available to > GET, and assign URIs, > > - consider cacheability, atomicity, and performance of sync operations > (for instance, syncing large collections), > > - be careful with new HTTP methods -- avoid them for things that are no= t > of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that > certain platforms (HTML forms, Flash...) can't use them, > > - when defining formats, also define internet media types. > > Also, in the last few months, new (and not so new) techniques have > finally been published as RFCs, such as: > > - HTTP PATCH method (RFC 5789) > > - HTTP Link Header and Link Relations Registry > (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in th= e > RFC Editor queue) > > - Service Discovery through well-known URIs (RFC 5785) > > Another potential building block are URI templates (work in progress: > http://tools.ietf.org/html/draft-gregorio-uritemplate-04) > > Considering all of these pieces, it's quite obvious that there's a > number of specs that would be useful on their own, but could also, > combined together, form the basis of an interesting authoring protocol: > > > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation > format. > > Can we re-use the WebDAV collection model here? Web application authors > probably would prefer a JSON representation, so can we simply define > this as an alternate representation of a DAV:multistatus description of > a collection? > > 2) Define namespace operations in terms of manipulating collection > representations (also consider a mapping to COPY/MOVE). > > 3) Define a media type to use with PATCH for modifying these > representations. > > 4) Define a property model (something like the intersection between > WebDAV properties and Java Content Repository (JSR-283) properties?) > > > # Authoring through HTML forms and POST > > Define how POST with multipart/form-data (RFC 2388) can be used for > authoring both content and properties. > > > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collections > (URI templates?). Or maybe link relations for collection navigation > (similar work for versioning: RFC 5829). > > > # Improvements to WebDAV > > 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this > question comes up quite frequently). > > 2) Define how to use POST on WebDAV collections to add members (done: > see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC > Editor queue). > > 3) Define media types (multiple?) for DAV:multistatus. > > 4) Define a discovery mechanism for GETtable representations of > PROPFIND/REPORT results (old proposal: > http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest= .html).=20 > > > 5) Define a mapping between link-typed WebDAV properties and generic > Link relations (see proposal: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). > > Although some of this will only be partially related to WebDAV, we thin= k > that this mailing list might be a good venue for discussion. > > > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format > for it (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. > > Extensions to WebDAV and mappings from/to WebDAV could be useful, but > would not be a core part of this activity. (That is, we can do without > if no volunteers speak up). > > Note that not all of these specs necessarily need to be on the > standards track; for instance, there might be candidates for > Informational RFCs as well (see > for details). > > > Feedback appreciated. > > Julian Reschke > David N=FCscheler > > > > PS: people not familiar with the IETF may want to have a look at > > --------------010400060507060605090801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [re-post from atom-protocol@mic.org at Julian's request]

You might consider looking at multipart/related POST of XML (or JSON) and document content data.

An XForms binding would also be a good match, since XForms is designed to be a REST client, and it has good support for structured XML data such as Atom, and for POST and PUT of multipart/related data.

XForms already has a high adoption rate in the CMS / ECM industry already (our own product DocuShare, Documentum/EMC, Alfresco, Atlassian, Nuxeo, SmartSite iXperion, MarkLogic, etc.)

There are good, free JavaScript implementations of XForms (Ubiquity XForms from IBM et al, XSLTForms from AgenceXML) and free server-side ones as well (Orbeon, Betterforms, etc.). 

Not all of these free implementations support multipart/related POST of XML with attached documents, but until browser support for MVC frameworks gets better, you can define an alternate wire syntax using multipart/form-data with one field containing a string of XML.  A similar approach has been used in old implementations of JavaScript's XHR which don't support DELETE and PUT, by setting a well-known header to communicate the real intent and using POST.


Leigh Klotz
Xerox Corp.

On 08/12/2010 02:50 AM, Julian Reschke wrote:
Fwd: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange

FYI - a proposal for collaboration on an authoring protocol that would
be more browser-friendly than WebDAV or AtomPub -- for now we started
discussion on the IETF WebDAV mailing list (hosted by the W3C).

Feedback appreciated.

-------- Original Message --------
Subject: Proposal for work on an efficient, browser-friendly, HTTP-based
communication protocol for fine-grained information exchange
Date: Thu, 12 Aug 2010 10:36:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
To: WebDAV <w3c-dist-auth@w3.org>

Proposal for work on an efficient, browser-friendly, HTTP-based
communication protocol for fine-grained information exchange

HTTP/1.1 (RFC 2616) already contains a set of tools for modifying
resources , namely the methods PUT, POST, and DELETE.

Many systems have been built on top of this, most of them in an ad-hoc
manner (which is ok when client and server are controlled by the same
developers).

We would like to cover some of the following use cases extending the
resource oriented model.

(1) An simple javascript based browser application should be able to
read fine-grained information (comparable to WebDAV properties) in a
simple manner using a defined JSON format to be consumed in an intuitive
fashion.

(2) A simple HTML Form should be able to write information in a patch
oriented manner containing both binary (file) data and fine-grained,
typed information using a multipart POST.

(3) A simple javascript application should be able to write information
in a patch oriented fashion using a defined JSON-diff PATCH content-type
to update fine-grained information.

There are also several extensions/applications of HTTP in this space,
such as:

- WebDAV (RFC 4918), which defines (a) a collection model and methods to
manipulate collections/namespaces, (b) a metadata (=property) model, and
(c) locking. Other RFCs add extensions on top of this, such as
Versioning (RFC 3253) and ACLs (RFC 3744).

- The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler,
not necessarily hierarchic collection model (which, depending on the use
case, may be a plus), but does not provide many features WebDAV +
friends define. Notably, namespace operations are absent.

WebDAV and AtomPub have been very successful so far. WebDAV gets used
both as a plain remote filesystem protocol (as observed by clients being
shipped with all operating systems, and both Apache httpd and IIS
supporting it), and for specific applications, such as Versioning
(subversion), Calendaring (CalDAV), etc. The same is true for AtomPub,
which actually may not be used a lot in practice for the original use
case (feed authoring), but for many other things instead.

Both of those protocol specifications are not easily consumed by
websites and applications running current browsers and require a lot of
client-sided scripting to cover simple read and write use cases.

There's a proposal for a protocol called "JSOP", which addresses these
use cases, which we may want to consider as input for this work:
<http://www.slideshare.net/uncled/jsop>

So what's wrong with WebDAV?

Since the time WebDAV was designed, we have learned a lot how to use the
Web and HTTP. Such as:

- if you want to expose data for read operations, make it available to
GET, and assign URIs,

- consider cacheability, atomicity, and performance of sync operations
(for instance, syncing large collections),

- be careful with new HTTP methods -- avoid them for things that are not
of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that
certain platforms (HTML forms, Flash...) can't use them,

- when defining formats, also define internet media types.

Also, in the last few months, new (and not so new) techniques have
finally been published as RFCs, such as:

- HTTP PATCH method (RFC 5789)

- HTTP Link Header and Link Relations Registry
(http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in the
RFC Editor queue)

- Service Discovery through well-known URIs (RFC 5785)

Another potential building block are URI templates (work in progress:
http://tools.ietf.org/html/draft-gregorio-uritemplate-04)

Considering all of these pieces, it's quite obvious that there's a
number of specs that would be useful on their own, but could also,
combined together, form the basis of an interesting authoring protocol:


# Data Model

1) Define a collection model (hierarchy, naming), and a representation
format.

Can we re-use the WebDAV collection model here? Web application authors
probably would prefer a JSON representation, so can we simply define
this as an alternate representation of a DAV:multistatus description of
a collection?

2) Define namespace operations in terms of manipulating collection
representations (also consider a mapping to COPY/MOVE).

3) Define a media type to use with PATCH for modifying these
representations.

4) Define a property model (something like the intersection between
WebDAV properties and Java Content Repository (JSR-283) properties?)


# Authoring through HTML forms and POST

Define how POST with multipart/form-data (RFC 2388) can be used for
authoring both content and properties.


# URIs for collection browsing

Assign either hardwired or discoverable URIs for inspecting collections
(URI templates?). Or maybe link relations for collection navigation
(similar work for versioning: RFC 5829).


# Improvements to WebDAV

1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this
question comes up quite frequently).

2) Define how to use POST on WebDAV collections to add members (done:
see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC
Editor queue).

3) Define media types (multiple?) for DAV:multistatus.

4) Define a discovery mechanism for GETtable representations of
PROPFIND/REPORT results (old proposal:
http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html).

5) Define a mapping between link-typed WebDAV properties and generic
Link relations (see proposal:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html).

Although some of this will only be partially related to WebDAV, we think
that this mailing list might be a good venue for discussion.


Expected deliverables from this activity would be:

1) Definition of a very simply data model and a representation format
for it (required JSON, optionally XML).

2) A format suitable for manipulating the data format above using PATCH
(potentially tunneled through POST).

3) A binding from multipart/form-data/POST to this model.

4) A separate (?) document explaining how these ingredients would be
combined in practice.

Extensions to WebDAV and mappings from/to WebDAV could be useful, but
would not be a core part of this activity. (That is, we can do without
if no volunteers speak up).

Note  that not all of these specs necessarily need to be on the
standards  track; for instance, there might be candidates for
Informational RFCs as  well (see
<http://tools.ietf.org/html/rfc2026#section-4> for details).


Feedback appreciated.

Julian Reschke
David Nüscheler



PS: people not familiar with the IETF may want to have a look at
<http://www.ietf.org/tao.html>



--------------010400060507060605090801-- From webdav-archive@ietf.org Fri Aug 13 13:22:05 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BF53A6A35 for ; Fri, 13 Aug 2010 13:22:04 -0700 (PDT) X-Quarantine-ID: <22RWWg8yPLwR> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -75.979 X-Spam-Level: X-Spam-Status: No, score=-75.979 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FB_GET_MEDS=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, TVD_RCVD_IP=1.931, 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 22RWWg8yPLwR for ; Fri, 13 Aug 2010 13:22:04 -0700 (PDT) Received: from 45-97-133-95.pool.ukrtel.net (45-97-133-95.pool.ukrtel.net [95.133.97.45]) by core3.amsl.com (Postfix) with SMTP id 4E5763A6852 for ; Fri, 13 Aug 2010 13:22:03 -0700 (PDT) Message-Id: <20100814000034.2967.qmail@45-97-133-95.pool.ukrtel.net> To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org VIAGRA ® Official Seller -86% From: webdav-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Fri, 13 Aug 2010 13:22:03 -0700 (PDT) Dear webdav-archive@ietf.org Get ready to make her happy. Discount price store: ID17024794 http://groups.yahoo.com/group/tufpvdaa/message We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From w3c-dist-auth-request@listhub.w3.org Fri Aug 13 18:04:18 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015683A6A49 for ; Fri, 13 Aug 2010 18:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.976 X-Spam-Level: X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 VfvCBh0TRxVe for ; Fri, 13 Aug 2010 18:04:15 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 99CC73A6A50 for ; Fri, 13 Aug 2010 18:04:15 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Ok59n-0002gi-Mu for w3c-dist-auth-dist@listhub.w3.org; Sat, 14 Aug 2010 01:03:31 +0000 Received: from wiggum.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok59m-0002fd-Ju for w3c-dist-auth@listhub.w3.org; Sat, 14 Aug 2010 01:03:30 +0000 Received: from nobody by wiggum.w3.org with local (Exim 4.63) (envelope-from ) id 1Ok59m-0005Yn-I4 for w3c-dist-auth@listhub.w3.org; Sat, 14 Aug 2010 01:03:30 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OjpEd-0005RH-K7 for w3c-dist-auth@listhub.w3.org; Fri, 13 Aug 2010 08:03:27 +0000 Received: from smtp-out.google.com ([216.239.44.51]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OjpEb-0002UT-Hk for w3c-dist-auth@w3.org; Fri, 13 Aug 2010 08:03:27 +0000 Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o7D82xO9019208 for ; Fri, 13 Aug 2010 01:02:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281686580; bh=czgRN5Df8h3qrWGpqX2flXYjaBo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=Ca18Uy11nDl5xCuSQD6DBUNPvc5X7EeikUcQw1Aok88LJuI1YJIcwdceAMirXK0Em Ww+7pBmL+RP2rdKP7S+Aw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: content-type:x-system-of-record; b=ueo6akC1TxzfMRIoxvMnfuo6gf3wDWNUXHgjbxa5NKf8XNIpoDDgmCYAv2sxl9DkU N3TpkGNZFPI4weyq64ilA== Received: from gwb15 (gwb15.prod.google.com [10.200.2.15]) by hpaq7.eem.corp.google.com with ESMTP id o7D82v9C015496 for ; Fri, 13 Aug 2010 01:02:57 -0700 Received: by gwb15 with SMTP id 15so889855gwb.20 for ; Fri, 13 Aug 2010 01:02:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.80.4 with SMTP id d4mr980393agb.11.1281686576748; Fri, 13 Aug 2010 01:02:56 -0700 (PDT) Received: by 10.91.220.17 with HTTP; Fri, 13 Aug 2010 01:02:56 -0700 (PDT) In-Reply-To: <4C63C650.1090301@gmx.de> References: <4C63C650.1090301@gmx.de> Date: Fri, 13 Aug 2010 01:02:56 -0700 Message-ID: From: Wenbo Zhu To: w3c-dist-auth@w3.org Content-Type: multipart/alternative; boundary=0016363109291eda58048dafe99c X-System-Of-Record: true Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1OjpEb-0002UT-Hk e7b6030aa2ccc2771921499a7f19fd4b X-caa-id: 1f1ce4247251052b5318 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13296 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 14 Aug 2010 01:03:31 +0000 --0016363109291eda58048dafe99c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Very plausible .. and comments inline. - Wenbo > -------- Original Message -------- > Subject: Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange > Date: Thu, 12 Aug 2010 10:36:59 +0200 > From: Julian Reschke > To: WebDAV > > Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange > > HTTP/1.1 (RFC 2616) already contains a set of tools for modifying > resources , namely the methods PUT, POST, and DELETE. > > Many systems have been built on top of this, most of them in an ad-hoc > manner (which is ok when client and server are controlled by the same > developers). > > We would like to cover some of the following use cases extending the > resource oriented model. > > (1) An simple javascript based browser application should be able to > read fine-grained information (comparable to WebDAV properties) in a > simple manner using a defined JSON format to be consumed in an intuitive > fashion. > > (2) A simple HTML Form should be able to write information in a patch > oriented manner containing both binary (file) data and fine-grained, > typed information using a multipart POST. > > (3) A simple javascript application should be able to write information > in a patch oriented fashion using a defined JSON-diff PATCH content-type > to update fine-grained information. > > There are also several extensions/applications of HTTP in this space, > such as: > > - WebDAV (RFC 4918), which defines (a) a collection model and methods to > manipulate collections/namespaces, (b) a metadata (=3Dproperty) model, an= d > (c) locking. Other RFCs add extensions on top of this, such as > Versioning (RFC 3253) and ACLs (RFC 3744). > > - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler, > not necessarily hierarchic collection model (which, depending on the use > case, may be a plus), but does not provide many features WebDAV + > friends define. Notably, namespace operations are absent. > > WebDAV and AtomPub have been very successful so far. WebDAV gets used > both as a plain remote filesystem protocol (as observed by clients being > shipped with all operating systems, and both Apache httpd and IIS > supporting it), and for specific applications, such as Versioning > (subversion), Calendaring (CalDAV), etc. The same is true for AtomPub, > which actually may not be used a lot in practice for the original use > case (feed authoring), but for many other things instead. > > Both of those protocol specifications are not easily consumed by > websites and applications running current browsers and require a lot of > client-sided scripting to cover simple read and write use cases. > > There's a proposal for a protocol called "JSOP", which addresses these > use cases, which we may want to consider as input for this work: > > > So what's wrong with WebDAV? > > Since the time WebDAV was designed, we have learned a lot how to use the > Web and HTTP. Such as: > > - if you want to expose data for read operations, make it available to > GET, and assign URIs, > > - consider cacheability, atomicity, and performance of sync operations > (for instance, syncing large collections), > > - be careful with new HTTP methods -- avoid them for things that are not > of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that > certain platforms (HTML forms, Flash...) can't use them, > > - when defining formats, also define internet media types. > > Also, in the last few months, new (and not so new) techniques have > finally been published as RFCs, such as: > > - HTTP PATCH method (RFC 5789) > > - HTTP Link Header and Link Relations Registry > (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in the > RFC Editor queue) > > - Service Discovery through well-known URIs (RFC 5785) > > Another potential building block are URI templates (work in progress: > http://tools.ietf.org/html/draft-gregorio-uritemplate-04) > > Considering all of these pieces, it's quite obvious that there's a > number of specs that would be useful on their own, but could also, > combined together, form the basis of an interesting authoring protocol: > > > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation > format. > > I have seen many debates around representation formats when the underlyin= g meta-model is often ignored ... and the meta-model should cover, in additio= n to hierarchy, relations. And naming should allow for different representations too, e.g. with the URI template[] being one of them. > Can we re-use the WebDAV collection model here? Web application authors > probably would prefer a JSON representation, so can we simply define > this as an alternate representation of a DAV:multistatus description of > a collection? > > 2) Define namespace operations in terms of manipulating collection > representations (also consider a mapping to COPY/MOVE). > > 3) Define a media type to use with PATCH for modifying these > representations. > > 4) Define a property model (something like the intersection between > WebDAV properties and Java Content Repository (JSR-283) properties?) > > > # Authoring through HTML forms and POST > > Define how POST with multipart/form-data (RFC 2388) can be used for > authoring both content and properties. > > > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collections > (URI templates?). Or maybe link relations for collection navigation > (similar work for versioning: RFC 5829). > > > # Improvements to WebDAV > > 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this > question comes up quite frequently). > > 2) Define how to use POST on WebDAV collections to add members (done: > see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC > Editor queue). > > 3) Define media types (multiple?) for DAV:multistatus. > > 4) Define a discovery mechanism for GETtable representations of > PROPFIND/REPORT results (old proposal: > > http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.h= tml > ). > > 5) Define a mapping between link-typed WebDAV properties and generic > Link relations (see proposal: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). > > Although some of this will only be partially related to WebDAV, we think > that this mailing list might be a good venue for discussion. > > > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format > for it (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. > > Extensions to WebDAV and mappings from/to WebDAV could be useful, but > would not be a core part of this activity. (That is, we can do without > if no volunteers speak up). > Resource-based concurrency-control and sync (revision logs) specs may be developed on top of these deliverables as well. > > Note that not all of these specs necessarily need to be on the > standards track; for instance, there might be candidates for > Informational RFCs as well (see > for details). > > > Feedback appreciated. > > Julian Reschke > David N=FCscheler > > > > PS: people not familiar with the IETF may want to have a look at > > > > --0016363109291eda58048dafe99c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
-------- Original Message --------
Subject: Proposal for work on an efficient, browser-friendly, HTTP-based co= mmunication protocol for fine-grained information exchange
Date: Thu, 12 Aug 2010 10:36:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
To: WebDAV <w3= c-dist-auth@w3.org>

Proposal for work on an efficient, browser-friendly, HTTP-based
communication protocol for fine-grained information exchange

HTTP/1.1 (RFC 2616) already contains a set of tools for modifying
resources , namely the methods PUT, POST, and DELETE.

Many systems have been built on top of this, most of them in an ad-hoc
manner (which is ok when client and server are controlled by the same
developers).

We would like to cover some of the following use cases extending the
resource oriented model.

(1) An simple javascript based browser application should be able to
read fine-grained information (comparable to WebDAV properties) in a
simple manner using a defined JSON format to be consumed in an intuitive fashion.

(2) A simple HTML Form should be able to write information in a patch
oriented manner containing both binary (file) data and fine-grained,
typed information using a multipart POST.

(3) A simple javascript application should be able to write information
in a patch oriented fashion using a defined JSON-diff PATCH content-type to update fine-grained information.

There are also several extensions/applications of HTTP in this space,
such as:

- WebDAV (RFC 4918), which defines (a) a collection model and methods to manipulate collections/namespaces, (b) a metadata (=3Dproperty) model, and<= br> (c) locking. Other RFCs add extensions on top of this, such as
Versioning (RFC 3253) and ACLs (RFC 3744).

- The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler,
not necessarily hierarchic collection model (which, depending on the use case, may be a plus), but does not provide many features WebDAV +
friends define. Notably, namespace operations are absent.

WebDAV and AtomPub have been very successful so far. WebDAV gets used
both as a plain remote filesystem protocol (as observed by clients being shipped with all operating systems, and both Apache httpd and IIS
supporting it), and for specific applications, such as Versioning
(subversion), Calendaring (CalDAV), etc. The same is true for AtomPub,
which actually may not be used a lot in practice for the original use
case (feed authoring), but for many other things instead.

Both of those protocol specifications are not easily consumed by
websites and applications running current browsers and require a lot of
client-sided scripting to cover simple read and write use cases.

There's a proposal for a protocol called "JSOP", which addres= ses these
use cases, which we may want to consider as input for this work:
<htt= p://www.slideshare.net/uncled/jsop>

So what's wrong with WebDAV?

Since the time WebDAV was designed, we have learned a lot how to use the Web and HTTP. Such as:

- if you want to expose data for read operations, make it available to
GET, and assign URIs,

- consider cacheability, atomicity, and performance of sync operations
(for instance, syncing large collections),

- be careful with new HTTP methods -- avoid them for things that are not of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that
certain platforms (HTML forms, Flash...) can't use them,

- when defining formats, also define internet media types.

Also, in the last few months, new (and not so new) techniques have
finally been published as RFCs, such as:

- HTTP PATCH method (RFC 5789)

- HTTP Link Header and Link Relations Registry
(http://tools.ietf.org/html/draft-nottingham-http-link-h= eader-10, in the
RFC Editor queue)

- Service Discovery through well-known URIs (RFC 5785)

Another potential building block are URI templates (work in progress:
http://tools.ietf.org/html/draft-gregorio-uritemplate-04)
Considering all of these pieces, it's quite obvious that there's a<= br> number of specs that would be useful on their own, but could also,
combined together, form the basis of an interesting authoring protocol:


# Data Model

1) Define a collection model (hierarchy, naming), and a representation
format.

I have s= een many debates around representation formats when the underlying meta-mod= el is often ignored ... and the meta-model should cover, in addition to hie= rarchy, relations. And naming should allow for different representations to= o, e.g. with the URI template[]=A0being one of them.
=A0
Can we re-use the WebDAV collection model here? Web application authors
probably would prefer a JSON representation, so can we simply define
this as an alternate representation of a DAV:multistatus description of
a collection?

2) Define namespace operations in terms of manipulating collection
representations (also consider a mapping to COPY/MOVE).

3) Define a media type to use with PATCH for modifying these
representations.

4) Define a property model (something like the intersection between
WebDAV properties and Java Content Repository (JSR-283) properties?)


# Authoring through HTML forms and POST

Define how POST with multipart/form-data (RFC 2388) can be used for
authoring both content and properties.


# URIs for collection browsing

Assign either hardwired or discoverable URIs for inspecting collections
(URI templates?). Or maybe link relations for collection navigation
(similar work for versioning: RFC 5829).


# Improvements to WebDAV

1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this
question comes up quite frequently).

2) Define how to use POST on WebDAV collections to add members (done:
see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-p= ost, in RFC
Editor queue).

3) Define media types (multiple?) for DAV:multistatus.

4) Define a discovery mechanism for GETtable representations of
PROPFIND/REPORT results (old proposal:
http://greenbytes.de/tech/webdav/draft-resc= hke-http-get-location-latest.html).

5) Define a mapping between link-typed WebDAV properties and generic
Link relations (see proposal:
http://lists.w3.org/Archives/Public/w3c-dist-auth= /2008OctDec/0026.html).

Although some of this will only be partially related to WebDAV, we think that this mailing list might be a good venue for discussion.


Expected deliverables from this activity would be:

1) Definition of a very simply data model and a representation format
for it (required JSON, optionally XML).

2) A format suitable for manipulating the data format above using PATCH
(potentially tunneled through POST).

3) A binding from multipart/form-data/POST to this model.

4) A separate (?) document explaining how these ingredients would be
combined in practice.

Extensions to WebDAV and mappings from/to WebDAV could be useful, but
would not be a core part of this activity. (That is, we can do without
if no volunteers speak up).

Resource-based concurrency-control and sy= nc (revision logs) specs may be developed on top of these deliverables as w= ell.
=A0

Note =A0that not all of these specs necessarily need to be on the
standards =A0track; for instance, there might be candidates for
Informational RFCs as =A0well (see
<http://tools.ietf.org/html/rfc2026#section-4> for details).


Feedback appreciated.

Julian Reschke
David N=FCscheler



PS: people not familiar with the IETF may want to have a look at
<http://www.i= etf.org/tao.html>



--0016363109291eda58048dafe99c-- From w3c-dist-auth-request@listhub.w3.org Fri Aug 13 18:58:44 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53F343A680C for ; Fri, 13 Aug 2010 18:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 p+Iq5ec3Q3Wl for ; Fri, 13 Aug 2010 18:58:42 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 213F03A687C for ; Fri, 13 Aug 2010 18:58:41 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Ok618-0002fS-Lx for w3c-dist-auth-dist@listhub.w3.org; Sat, 14 Aug 2010 01:58:38 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok616-0002e2-J3; Sat, 14 Aug 2010 01:58:36 +0000 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok614-0001RL-55; Sat, 14 Aug 2010 01:58:36 +0000 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7E1hQRn025649; Fri, 13 Aug 2010 21:43:26 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7E1w2RA130078; Fri, 13 Aug 2010 21:58:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7E1w2ng004215; Fri, 13 Aug 2010 21:58:02 -0400 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7E1w284004209; Fri, 13 Aug 2010 21:58:02 -0400 In-Reply-To: <4C63B2AB.6090701@gmx.de> References: <4C63B2AB.6090701@gmx.de> X-KeepSent: A38A80AA:050D584C-8525777F:000A0017; type=4; name=$KeepSent To: Julian Reschke Cc: WebDAV , w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: Geoffrey M Clemm Date: Fri, 13 Aug 2010 21:58:00 -0400 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 8.0.1|February 07, 2008) at 08/13/2010 21:58:01 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFDECDF9986878f9e8a93df938690918c0ABBFDECDF998687" Content-Disposition: inline Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1Ok614-0001RL-55 be0b0b784e9655ea78ffd3501c07e3d5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13297 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 14 Aug 2010 01:58:38 +0000 --0__=0ABBFDECDF9986878f9e8a93df938690918c0ABBFDECDF998687 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable One of the things I'd like to see with this work is to settle the vario= us syntax debates, by just defining mappings to a variety of syntaxes. One key part of this is already identified below, i.e. define a GET URI= scheme for any method that involves reading data. In addition, define a POST body syntax for any method that is not in HTTP/1.1. Finally, define an AtomPub and JSON variant, in addition to the XML tha= t WebDAV would normally use. This would then allow us to focus on the semantics, and avoid all the syntax debates. And if a particular syntax has trouble expressing some of the semantics= , that would highlight why one syntax might be preferable to another.. Cheers, Geoff Julian Reschke wrote on 08/12/2010 04:36:59 AM: > Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange > > HTTP/1.1 (RFC 2616) already contains a set of tools for modifying > resources , namely the methods PUT, POST, and DELETE. > > Many systems have been built on top of this, most of them in an ad-ho= c > manner (which is ok when client and server are controlled by the same= > developers). > > We would like to cover some of the following use cases extending the > resource oriented model. > > (1) An simple javascript based browser application should be able to > read fine-grained information (comparable to WebDAV properties) in a > simple manner using a defined JSON format to be consumed in an intuit= ive > fashion. > > (2) A simple HTML Form should be able to write information in a patch= > oriented manner containing both binary (file) data and fine-grained, > typed information using a multipart POST. > > (3) A simple javascript application should be able to write informati= on > in a patch oriented fashion using a defined JSON-diff PATCH content-t= ype > to update fine-grained information. > > There are also several extensions/applications of HTTP in this space,= > such as: > > - WebDAV (RFC 4918), which defines (a) a collection model and methods= to > manipulate collections/namespaces, (b) a metadata (=3Dproperty) model= , and > (c) locking. Other RFCs add extensions on top of this, such as > Versioning (RFC 3253) and ACLs (RFC 3744). > > - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simple= r, > not necessarily hierarchic collection model (which, depending on the = use > case, may be a plus), but does not provide many features WebDAV + > friends define. Notably, namespace operations are absent. > > WebDAV and AtomPub have been very successful so far. WebDAV gets used= > both as a plain remote filesystem protocol (as observed by clients be= ing > shipped with all operating systems, and both Apache httpd and IIS > supporting it), and for specific applications, such as Versioning > (subversion), Calendaring (CalDAV), etc. The same is true for AtomPub= , > which actually may not be used a lot in practice for the original use= > case (feed authoring), but for many other things instead. > > Both of those protocol specifications are not easily consumed by > websites and applications running current browsers and require a lot = of > client-sided scripting to cover simple read and write use cases. > > There's a proposal for a protocol called "JSOP", which addresses thes= e > use cases, which we may want to consider as input for this work: > > > So what's wrong with WebDAV? > > Since the time WebDAV was designed, we have learned a lot how to use = the > Web and HTTP. Such as: > > - if you want to expose data for read operations, make it available t= o > GET, and assign URIs, > > - consider cacheability, atomicity, and performance of sync operation= s > (for instance, syncing large collections), > > - be careful with new HTTP methods -- avoid them for things that are = not > of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that > certain platforms (HTML forms, Flash...) can't use them, > > - when defining formats, also define internet media types. > > Also, in the last few months, new (and not so new) techniques have > finally been published as RFCs, such as: > > - HTTP PATCH method (RFC 5789) > > - HTTP Link Header and Link Relations Registry > (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in = the > RFC Editor queue) > > - Service Discovery through well-known URIs (RFC 5785) > > Another potential building block are URI templates (work in progress:= > http://tools.ietf.org/html/draft-gregorio-uritemplate-04) > > Considering all of these pieces, it's quite obvious that there's a > number of specs that would be useful on their own, but could also, > combined together, form the basis of an interesting authoring protoco= l: > > > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representatio= n > format. > > Can we re-use the WebDAV collection model here? Web application autho= rs > probably would prefer a JSON representation, so can we simply define > this as an alternate representation of a DAV:multistatus description = of > a collection? > > 2) Define namespace operations in terms of manipulating collection > representations (also consider a mapping to COPY/MOVE). > > 3) Define a media type to use with PATCH for modifying these > representations. > > 4) Define a property model (something like the intersection between > WebDAV properties and Java Content Repository (JSR-283) properties?) > > > # Authoring through HTML forms and POST > > Define how POST with multipart/form-data (RFC 2388) can be used for > authoring both content and properties. > > > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collectio= ns > (URI templates?). Or maybe link relations for collection navigation > (similar work for versioning: RFC 5829). > > > # Improvements to WebDAV > > 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (thi= s > question comes up quite frequently). > > 2) Define how to use POST on WebDAV collections to add members (done:= > see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in R= FC > Editor queue). > > 3) Define media types (multiple?) for DAV:multistatus. > > 4) Define a discovery mechanism for GETtable representations of > PROPFIND/REPORT results (old proposal: > http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest= .html). > > 5) Define a mapping between link-typed WebDAV properties and generic > Link relations (see proposal: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.htm= l). > > Although some of this will only be partially related to WebDAV, we th= ink > that this mailing list might be a good venue for discussion. > > > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format= > for it (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PAT= CH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. > > Extensions to WebDAV and mappings from/to WebDAV could be useful, but= > would not be a core part of this activity. (That is, we can do withou= t > if no volunteers speak up). > > Note that not all of these specs necessarily need to be on the > standards track; for instance, there might be candidates for > Informational RFCs as well (see > for details). > > > Feedback appreciated. > > Julian Reschke > David N=FCscheler > > > > PS: people not familiar with the IETF may want to have a look at > > >= --0__=0ABBFDECDF9986878f9e8a93df938690918c0ABBFDECDF998687 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

One of the things I'd like to see with this work is to settle the va= rious syntax debates, by just defining mappings to a variety of syntaxe= s.

One key part of this is already identified below, i.e. define a GET URI= scheme for any method that involves reading data.
In addition, define a POST body syntax for any method that is not in HT= TP/1.1.
Finally, define an AtomPub and JSON variant, in addition to the XML tha= t WebDAV would normally use.

This would then allow us to focus on the semantics, and avoid all the s= yntax debates.
And if a particular syntax has trouble expressing some of the semantics= , that would highlight why one syntax might be preferable to another.
Cheers,
Geoff

Julian Reschke  wrote on 08/12/2010 04:36:59 AM:
> Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange
>
> HTTP/1.1 (RFC 2616) already contains a set of tools for modifying =
> resources , namely the methods PUT, POST, and DELETE.
>
> Many systems have been built on top of this, most of them in an ad= -hoc
> manner (which is ok when client and server are controlled by the s= ame
> developers).
>
> We would like to cover some of the following use cases extending t= he
> resource oriented model.
>
> (1) An simple javascript based browser application should be able = to
> read fine-grained information (comparable to WebDAV properties) in= a
> simple manner using a defined JSON format to be consumed in an int= uitive
> fashion.
>
> (2) A simple HTML Form should be able to write information in a pa= tch
> oriented manner containing both binary (file) data and fine-graine= d,
> typed information using a multipart POST.
>
> (3) A simple javascript application should be able to write inform= ation
> in a patch oriented fashion using a defined JSON-diff PATCH conten= t-type
> to update fine-grained information.
>
> There are also several extensions/applications of HTTP in this spa= ce,
> such as:
>
> - WebDAV (RFC 4918), which defines (a) a collection model and meth= ods to
> manipulate collections/namespaces, (b) a metadata (=3Dproperty) mo= del, and
> (c) locking. Other RFCs add extensions on top of this, such as > Versioning (RFC 3253) and ACLs (RFC 3744).
>
> - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a sim= pler,
> not necessarily hierarchic collection model (which, depending on t= he use
> case, may be a plus), but does not provide many features WebDAV + =
> friends define. Notably, namespace operations are absent.
>
> WebDAV and AtomPub have been very successful so far. WebDAV gets u= sed
> both as a plain remote filesystem protocol (as observed by clients= being
> shipped with all operating systems, and both Apache httpd and IIS =
> supporting it), and for specific applications, such as Versioning =
> (subversion), Calendaring (CalDAV), etc. The same is true for Atom= Pub,
> which actually may not be used a lot in practice for the original = use
> case (feed authoring), but for many other things instead.
>
> Both of those protocol specifications are not easily consumed by <= br> > websites and applications running current browsers and require a l= ot of
> client-sided scripting to cover simple read and write use cases. >
> There's a proposal for a protocol called "JSOP", which a= ddresses these
> use cases, which we may want to consider as input for this work: <= br> > <http://www.s= lideshare.net/uncled/jsop>
>
> So what's wrong with WebDAV?
>
> Since the time WebDAV was designed, we have learned a lot how to u= se the
> Web and HTTP. Such as:
>
> - if you want to expose data for read operations, make it availabl= e to
> GET, and assign URIs,
>
> - consider cacheability, atomicity, and performance of sync operat= ions
> (for instance, syncing large collections),
>
> - be careful with new HTTP methods -- avoid them for things that a= re not
> of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind tha= t
> certain platforms (HTML forms, Flash...) can't use them,
>
> - when defining formats, also define internet media types.
>
> Also, in the last few months, new (and not so new) techniques have=
> finally been published as RFCs, such as:
>
> - HTTP PATCH method (RFC 5789)
>
> - HTTP Link Header and Link Relations Registry
> (http://tools.ietf.org/html/draft-nottingham-http-link-header= -10, in the
> RFC Editor queue)
>
> - Service Discovery through well-known URIs (RFC 5785)
>
> Another potential building block are URI templates (work in progre= ss:
> http://tools.ietf.org/html/draft-gregorio-uritemplate-04)
>
> Considering all of these pieces, it's quite obvious that there's a=
> number of specs that would be useful on their own, but could also,=
> combined together, form the basis of an interesting authoring prot= ocol:
>
>
> # Data Model
>
> 1) Define a collection model (hierarchy, naming), and a representa= tion
> format.
>
> Can we re-use the WebDAV collection model here? Web application au= thors
> probably would prefer a JSON representation, so can we simply defi= ne
> this as an alternate representation of a DAV:multistatus descripti= on of
> a collection?
>
> 2) Define namespace operations in terms of manipulating collection=
> representations (also consider a mapping to COPY/MOVE).
>
> 3) Define a media type to use with PATCH for modifying these
> representations.
>
> 4) Define a property model (something like the intersection betwee= n
> WebDAV properties and Java Content Repository (JSR-283) properties= ?)
>
>
> # Authoring through HTML forms and POST
>
> Define how POST with multipart/form-data (RFC 2388) can be used fo= r
> authoring both content and properties.
>
>
> # URIs for collection browsing
>
> Assign either hardwired or discoverable URIs for inspecting collec= tions
> (URI templates?). Or maybe link relations for collection navigatio= n
> (similar work for versioning: RFC 5829).
>
>
> # Improvements to WebDAV
>
> 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (= this
> question comes up quite frequently).
>
> 2) Define how to use POST on WebDAV collections to add members (do= ne:
> see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC
> Editor queue).
>
> 3) Define media types (multiple?) for DAV:multistatus.
>
> 4) Define a discovery mechanism for GETtable representations of > PROPFIND/REPORT results (old proposal:
> http://greenbytes.de/tech/webdav/draft-reschke-h= ttp-get-location-latest.html).
>
> 5) Define a mapping between link-typed WebDAV properties and gener= ic
> Link relations (see proposal:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2008= OctDec/0026.html).
>
> Although some of this will only be partially related to WebDAV, we= think
> that this mailing list might be a good venue for discussion.
>
>
> Expected deliverables from this activity would be:
>
> 1) Definition of a very simply data model and a representation for= mat
> for it (required JSON, optionally XML).
>
> 2) A format suitable for manipulating the data format above using = PATCH
> (potentially tunneled through POST).
>
> 3) A binding from multipart/form-data/POST to this model.
>
> 4) A separate (?) document explaining how these ingredients would = be
> combined in practice.
>
> Extensions to WebDAV and mappings from/to WebDAV could be useful, = but
> would not be a core part of this activity. (That is, we can do wit= hout
> if no volunteers speak up).
>
> Note  that not all of these specs necessarily need to be on t= he
> standards  track; for instance, there might be candidates for=
> Informational RFCs as  well (see
> <http:= //tools.ietf.org/html/rfc2026#section-4> for details).
>
>
> Feedback appreciated.
>
> Julian Reschke
> David N=FCscheler
>
>
>
> PS: people not familiar with the IETF may want to have a look at <= br> > <http://www.ietf.org/t= ao.html>
>
>
= --0__=0ABBFDECDF9986878f9e8a93df938690918c0ABBFDECDF998687-- From w3c-dist-auth-request@listhub.w3.org Fri Aug 13 20:15:23 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FE13A6A7A for ; Fri, 13 Aug 2010 20:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zf6fsl7AVDK for ; Fri, 13 Aug 2010 20:15:22 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 8F4D23A6A75 for ; Fri, 13 Aug 2010 20:15:21 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Ok7Ct-0000fl-Cf for w3c-dist-auth-dist@listhub.w3.org; Sat, 14 Aug 2010 03:14:51 +0000 Received: from wiggum.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok7Cr-0000eA-Dz for w3c-dist-auth@listhub.w3.org; Sat, 14 Aug 2010 03:14:49 +0000 Received: from nobody by wiggum.w3.org with local (Exim 4.63) (envelope-from ) id 1Ok7Cr-0001Ih-9r for w3c-dist-auth@listhub.w3.org; Sat, 14 Aug 2010 03:14:49 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ojc01-0000hS-KL for w3c-dist-auth@listhub.w3.org; Thu, 12 Aug 2010 17:55:29 +0000 Received: from mail-ew0-f43.google.com ([209.85.215.43]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ojbzz-0003g6-To for w3c-dist-auth@w3.org; Thu, 12 Aug 2010 17:55:29 +0000 Received: by ewy1 with SMTP id 1so1183346ewy.2 for ; Thu, 12 Aug 2010 10:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=3zZbP8l2XQVueHPtAVfICzIEYNUHTAwWjYSZKZPl0NQ=; b=YXX4Ppf/wn6xNCjwMlkF+AlBMQFYFZWJ2WYX8ISIZtdGRygY0KOHoM3qiaoCnkp317 gRsFcDGEihbKLJuSp222q4zqGe6rt0rXqPnTsv5GSaPPacYA5oztvgWFtW00oAHseSyM bMyd38yr3bVNA2dzCqWNSiyj+Fx28giySUYUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=D7sXx3MGzhrUKTjiiUtM0zKpkvPkRw4SnGByvpjwg78a4v5/hoIbeWwNBqYXtksWhQ JiYNKq/6aUuQE0WCiU7nPGnoxXgGGIqwJxIx/29fTsDIEaeYJX+Eb0m2UrSGeUaM9HdN 7rvsd7QXSE6tFKhSa6R+gDn8N88KQRfO3dUII= Received: by 10.213.31.134 with SMTP id y6mr520948ebc.82.1281635701814; Thu, 12 Aug 2010 10:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.47.10 with HTTP; Thu, 12 Aug 2010 10:54:41 -0700 (PDT) In-Reply-To: <4C63B2AB.6090701@gmx.de> References: <4C63B2AB.6090701@gmx.de> From: Jukka Zitting Date: Thu, 12 Aug 2010 19:54:41 +0200 Message-ID: To: WebDAV Content-Type: text/plain; charset=ISO-8859-1 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Ojbzz-0003g6-To 179a3c2ef91cbb59b7d7efddd45bebd3 X-caa-id: e36667b7edccf4434906 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13298 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 14 Aug 2010 03:14:51 +0000 Hi, On Thu, Aug 12, 2010 at 10:36 AM, Julian Reschke wrote: > Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange Sounds useful! See [1] for a few basic use cases and requirements I outlined for such a protocol last year. It seems like the proposed protocol could match these needs well, and I'd be eager to participate in ironing out the details. See below for some initial comments. [1] http://jukkaz.wordpress.com/2009/11/18/content-repository-over-http/ > [... WebDAV / Atom(Pub) ...] > Both of those protocol specifications are not easily consumed by websites > and applications running current browsers and require a lot of client-sided > scripting to cover simple read and write use cases. I'd add that also on server-side processing JSON or HTML forms is usually easier than handling WebDAV or AtomPub. > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation > format. > > Can we re-use the WebDAV collection model here? Web application authors > probably would prefer a JSON representation, so can we simply define this as > an alternate representation of a DAV:multistatus description of a > collection? It would be good if anything that can be expressed by this protocol could be straightforwardly mapped to WebDAV and/or Atom. The reverse does not need to be true, I'd rather go for simplicity than strive for a full one-to-one mapping with another protocol. > 4) Define a property model (something like the intersection between WebDAV > properties and Java Content Repository (JSR-283) properties?) As above, I'd focus on core property types shared by existing standards. > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collections (URI > templates?). Or maybe link relations for collection navigation (similar work > for versioning: RFC 5829). I'd rather avoid hardwiring URIs. > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format for it > (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. 5) A test suite for validating compliance of implementations. (Not sure if this fits the scope of deliverables from an IETF WG, but should at least be pursued as a parallel effort.) > PS: people not familiar with the IETF may want to have a look at > Thanks! This was my first post here, so let me briefly introduce myself: I've been working with open source content management since -97 and for the past few years I've been focusing on Apache Jackrabbit and other related Apache projects. I work for Day Software and have participated in the JCR standardization effort in the JCP. I'm from Finland, but currently based in Basel, Switzerland. BR, Jukka Zitting From ycimu5885@comcast.net Fri Aug 13 21:00:53 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213603A6A75 for ; Fri, 13 Aug 2010 21:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.741 X-Spam-Level: X-Spam-Status: No, score=-35.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 CuxeCdYZoWYQ for ; Fri, 13 Aug 2010 21:00:51 -0700 (PDT) Received: from comcast.net (c-71-228-209-74.hsd1.tn.comcast.net [71.228.209.74]) by core3.amsl.com (Postfix) with ESMTP id 2F0073A67D4 for ; Fri, 13 Aug 2010 21:00:51 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Fri, 13 Aug 2010 22:59:02 -0500 Subject: Amazing growth reported with our formulas Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100814040051.2F0073A67D4@core3.amsl.com> Need help in that department down there, no fear as we have the gear to giant size you. http://www.questtin.ru/ A b Sierra Leone - Annual report 2006. The belief was that the two languages were mutually exclusive and that learning a second required unlearning elements and dynamics of the first in order to accommodate the second (Hakuta, 1990). The neutrality of this section is disputed. In response to his physical weakness, he embraced a strenuous life. After wedding Thorild, he moved to Haukadal (Hawksdale) and built a farm there. Thanks to a Union-wide selection (there were "army" and "police" teams in most major cities) and Moscow being the centre of both the sports organisations, DoD and police headquarters, Spartak, CSKA and Dinamo were equally most prestigious, well-manned and funded teams in USSR. List of founders of religious traditions. Aziz Ansari (born February 23, 1983) is an American actor and comedian. From atudukaof7613@comcast.net Fri Aug 13 21:56:30 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA243A6898 for ; Fri, 13 Aug 2010 21:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.026 X-Spam-Level: X-Spam-Status: No, score=-26.026 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 m6jFiJn9eoKV for ; Fri, 13 Aug 2010 21:56:29 -0700 (PDT) Received: from comcast.net (c-67-160-160-81.hsd1.or.comcast.net [67.160.160.81]) by core3.amsl.com (Postfix) with ESMTP id 3ECBB3A6814 for ; Fri, 13 Aug 2010 21:56:29 -0700 (PDT) From: To: webdav-archive@ietf.org Date: Fri, 13 Aug 2010 21:57:04 -0700 Subject: Grow what you lack now Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100814045629.3ECBB3A6814@core3.amsl.com> Your love-making will be sensational after you get this http://www.riddlebeard.ru/ Austria-Hungary surrendered in early November 1918. Paisley opposed the 1972 suspension by the British government of Edward Heath of the Northern Ireland parliament and government (known as Stormont due to the location of Parliament Buildings on the Stormont estate). The Diana Jones Award committee. If the offense fails to gain a first down (10 yards) after 4 downs, the other team gets possession of the ball at the point where the fourth down ended, beginning with their first down to advance the ball in the opposite direction. Bermudians began to turn to maritime trades relatively early in the 17th century, but the Somers Isles Company used all its authority to suppress turning away from agriculture. Hafiz, Divan-i-Hafiz, translated by Henry Wiberforce-Clarke, Ibex Publishers, Inc. Mechanical reliability became an issue, but the experiment proved its worth. Anthony Fox, The Structure of German (2005) ISBN 0199273995. From w3c-dist-auth-request@listhub.w3.org Sat Aug 14 02:02:50 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09ED33A67A7 for ; Sat, 14 Aug 2010 02:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 svai0T7pH6Dd for ; Sat, 14 Aug 2010 02:02:47 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 32BE33A68F6 for ; Sat, 14 Aug 2010 02:02:45 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OkCcb-0008Uf-6E for w3c-dist-auth-dist@listhub.w3.org; Sat, 14 Aug 2010 09:01:45 +0000 Received: from wiggum.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OkCcZ-0008SB-G3 for w3c-dist-auth@listhub.w3.org; Sat, 14 Aug 2010 09:01:43 +0000 Received: from nobody by wiggum.w3.org with local (Exim 4.63) (envelope-from ) id 1OkCcZ-0006Fi-G3 for w3c-dist-auth@listhub.w3.org; Sat, 14 Aug 2010 09:01:43 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok20u-0003M6-8u for w3c-dist-auth@listhub.w3.org; Fri, 13 Aug 2010 21:42:08 +0000 Received: from smtp-out.google.com ([74.125.121.35]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ok20r-0000Xt-JM for w3c-dist-auth@w3.org; Fri, 13 Aug 2010 21:42:08 +0000 Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o7DLfcSN031192 for ; Fri, 13 Aug 2010 14:41:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281735699; bh=RQgmBKfAyXDZRE1JQ/eOoar9aRg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=u9wI1W0GHHamp0cKxdghA7U7nNjTtS+w4FNJjh/zDgX4UY2GYdjD3TX4gz8Z8FcX3 8Y5oMs59TQxDFYWhcXZAA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: content-type:x-system-of-record; b=STLIUaHftdYFPdnzoBAgh/3mxDaSB2fq168gObkGmBZuLTKbIbAUAAokLEyo+mxjm Twkld9696J31W/k+EofzQ== Received: from ywj3 (ywj3.prod.google.com [10.192.10.3]) by kpbe17.cbf.corp.google.com with ESMTP id o7DLfapc031758 for ; Fri, 13 Aug 2010 14:41:37 -0700 Received: by ywj3 with SMTP id 3so1670515ywj.10 for ; Fri, 13 Aug 2010 14:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.88.7 with SMTP id l7mr1629181agb.150.1281735690678; Fri, 13 Aug 2010 14:41:30 -0700 (PDT) Received: by 10.91.220.17 with HTTP; Fri, 13 Aug 2010 14:41:30 -0700 (PDT) In-Reply-To: References: <4C63C650.1090301@gmx.de> Date: Fri, 13 Aug 2010 14:41:30 -0700 Message-ID: From: Wenbo Zhu To: w3c-dist-auth Content-Type: multipart/alternative; boundary=0016361e89be89f1b5048dbb589d X-System-Of-Record: true Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1Ok20r-0000Xt-JM fce48a0dcd28db6aef92acbdfc7c46e5 X-caa-id: 9075dc85957adc04a1ab X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13299 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sat, 14 Aug 2010 09:01:45 +0000 --0016361e89be89f1b5048dbb589d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [re-repost] Very plausible .. and comments inline. - Wenbo > -------- Original Message -------- > > Subject: Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange > Date: Thu, 12 Aug 2010 10:36:59 +0200 > From: Julian Reschke > To: WebDAV > > Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange > > HTTP/1.1 (RFC 2616) already contains a set of tools for modifying > resources , namely the methods PUT, POST, and DELETE. > > Many systems have been built on top of this, most of them in an ad-hoc > manner (which is ok when client and server are controlled by the same > developers). > > We would like to cover some of the following use cases extending the > resource oriented model. > > (1) An simple javascript based browser application should be able to > read fine-grained information (comparable to WebDAV properties) in a > simple manner using a defined JSON format to be consumed in an intuitive > fashion. > > (2) A simple HTML Form should be able to write information in a patch > oriented manner containing both binary (file) data and fine-grained, > typed information using a multipart POST. > > (3) A simple javascript application should be able to write information > in a patch oriented fashion using a defined JSON-diff PATCH content-type > to update fine-grained information. > > There are also several extensions/applications of HTTP in this space, > such as: > > - WebDAV (RFC 4918), which defines (a) a collection model and methods to > manipulate collections/namespaces, (b) a metadata (=3Dproperty) model, an= d > (c) locking. Other RFCs add extensions on top of this, such as > Versioning (RFC 3253) and ACLs (RFC 3744). > > - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler, > not necessarily hierarchic collection model (which, depending on the use > case, may be a plus), but does not provide many features WebDAV + > friends define. Notably, namespace operations are absent. > > WebDAV and AtomPub have been very successful so far. WebDAV gets used > both as a plain remote filesystem protocol (as observed by clients being > shipped with all operating systems, and both Apache httpd and IIS > supporting it), and for specific applications, such as Versioning > (subversion), Calendaring (CalDAV), etc. The same is true for AtomPub, > which actually may not be used a lot in practice for the original use > case (feed authoring), but for many other things instead. > > Both of those protocol specifications are not easily consumed by > websites and applications running current browsers and require a lot of > client-sided scripting to cover simple read and write use cases. > > There's a proposal for a protocol called "JSOP", which addresses these > use cases, which we may want to consider as input for this work: > > > So what's wrong with WebDAV? > > Since the time WebDAV was designed, we have learned a lot how to use the > Web and HTTP. Such as: > > - if you want to expose data for read operations, make it available to > GET, and assign URIs, > > - consider cacheability, atomicity, and performance of sync operations > (for instance, syncing large collections), > > - be careful with new HTTP methods -- avoid them for things that are not > of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that > certain platforms (HTML forms, Flash...) can't use them, > > - when defining formats, also define internet media types. > > Also, in the last few months, new (and not so new) techniques have > finally been published as RFCs, such as: > > - HTTP PATCH method (RFC 5789) > > - HTTP Link Header and Link Relations Registry > (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in the > RFC Editor queue) > > - Service Discovery through well-known URIs (RFC 5785) > > Another potential building block are URI templates (work in progress: > http://tools.ietf.org/html/draft-gregorio-uritemplate-04) > > Considering all of these pieces, it's quite obvious that there's a > number of specs that would be useful on their own, but could also, > combined together, form the basis of an interesting authoring protocol: > > > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation > format. > > I have seen many debates around representation formats when the underlyin= g meta-model is often ignored ... and the meta-model should cover, in additio= n to hierarchy, relations. And naming should allow for different representations too, e.g. with the URI template[] being one of them. > Can we re-use the WebDAV collection model here? Web application authors > > probably would prefer a JSON representation, so can we simply define > this as an alternate representation of a DAV:multistatus description of > a collection? > > 2) Define namespace operations in terms of manipulating collection > representations (also consider a mapping to COPY/MOVE). > > 3) Define a media type to use with PATCH for modifying these > representations. > > 4) Define a property model (something like the intersection between > WebDAV properties and Java Content Repository (JSR-283) properties?) > > > # Authoring through HTML forms and POST > > Define how POST with multipart/form-data (RFC 2388) can be used for > authoring both content and properties. > > > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collections > (URI templates?). Or maybe link relations for collection navigation > (similar work for versioning: RFC 5829). > > > # Improvements to WebDAV > > 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this > question comes up quite frequently). > > 2) Define how to use POST on WebDAV collections to add members (done: > see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC > Editor queue). > > 3) Define media types (multiple?) for DAV:multistatus. > > 4) Define a discovery mechanism for GETtable representations of > PROPFIND/REPORT results (old proposal: > > http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.h= tml > ). > > 5) Define a mapping between link-typed WebDAV properties and generic > Link relations (see proposal: > http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). > > Although some of this will only be partially related to WebDAV, we think > that this mailing list might be a good venue for discussion. > > > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format > for it (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. > > Extensions to WebDAV and mappings from/to WebDAV could be useful, but > would not be a core part of this activity. (That is, we can do without > if no volunteers speak up). > Resource-based concurrency-control and sync (revision logs) specs may be developed on top of these deliverables as well. > > Note that not all of these specs necessarily need to be on the > standards track; for instance, there might be candidates for > Informational RFCs as well (see > for details). > > > Feedback appreciated. > > Julian Reschke > David N=FCscheler > > > > PS: people not familiar with the IETF may want to have a look at > > > > --0016361e89be89f1b5048dbb589d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

[re-repost]

Very plausible .. and comments inline. - We= nbo
=A0
-------- Original Message --------

Subject: Proposal for work on an efficient, browser-friendly, HTTP-based co= mmunication protocol for fine-grained information exchange
Date: Thu, 12 Aug 2010 10:36:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
To: WebDAV <w3= c-dist-auth@w3.org>

Proposal for work on an efficient, browser-friendly, HTTP-based
communication protocol for fine-grained information exchange

HTTP/1.1 (RFC 2616) already contains a set of tools for modifying
resources , namely the methods PUT, POST, and DELETE.

Many systems have been built on top of this, most of them in an ad-hoc
manner (which is ok when client and server are controlled by the same
developers).

We would like to cover some of the following use cases extending the
resource oriented model.

(1) An simple javascript based browser application should be able to
read fine-grained information (comparable to WebDAV properties) in a
simple manner using a defined JSON format to be consumed in an intuitive fashion.

(2) A simple HTML Form should be able to write information in a patch
oriented manner containing both binary (file) data and fine-grained,
typed information using a multipart POST.

(3) A simple javascript application should be able to write information
in a patch oriented fashion using a defined JSON-diff PATCH content-type to update fine-grained information.

There are also several extensions/applications of HTTP in this space,
such as:

- WebDAV (RFC 4918), which defines (a) a collection model and methods to manipulate collections/namespaces, (b) a metadata (=3Dproperty) model, and<= br> (c) locking. Other RFCs add extensions on top of this, such as
Versioning (RFC 3253) and ACLs (RFC 3744).

- The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler,
not necessarily hierarchic collection model (which, depending on the use case, may be a plus), but does not provide many features WebDAV +
friends define. Notably, namespace operations are absent.

WebDAV and AtomPub have been very successful so far. WebDAV gets used
both as a plain remote filesystem protocol (as observed by clients being shipped with all operating systems, and both Apache httpd and IIS
supporting it), and for specific applications, such as Versioning
(subversion), Calendaring (CalDAV), etc. The same is true for AtomPub,
which actually may not be used a lot in practice for the original use
case (feed authoring), but for many other things instead.

Both of those protocol specifications are not easily consumed by
websites and applications running current browsers and require a lot of
client-sided scripting to cover simple read and write use cases.

There's a proposal for a protocol called "JSOP", which addres= ses these
use cases, which we may want to consider as input for this work:
<htt= p://www.slideshare.net/uncled/jsop>

So what's wrong with WebDAV?

Since the time WebDAV was designed, we have learned a lot how to use the Web and HTTP. Such as:

- if you want to expose data for read operations, make it available to
GET, and assign URIs,

- consider cacheability, atomicity, and performance of sync operations
(for instance, syncing large collections),

- be careful with new HTTP methods -- avoid them for things that are not of generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that
certain platforms (HTML forms, Flash...) can't use them,

- when defining formats, also define internet media types.

Also, in the last few months, new (and not so new) techniques have
finally been published as RFCs, such as:

- HTTP PATCH method (RFC 5789)

- HTTP Link Header and Link Relations Registry
(http://tools.ietf.org/html/draft-nottingham-http-link-h= eader-10, in the
RFC Editor queue)

- Service Discovery through well-known URIs (RFC 5785)

Another potential building block are URI templates (work in progress:
http://tools.ietf.org/html/draft-gregorio-uritemplate-04)
Considering all of these pieces, it's quite obvious that there's a<= br> number of specs that would be useful on their own, but could also,
combined together, form the basis of an interesting authoring protocol:


# Data Model

1) Define a collection model (hierarchy, naming), and a representation
format.

I have seen = many debates around representation formats when the underlying meta-model i= s often ignored ... and the meta-model should cover, in addition to hierarc= hy, relations. And naming should allow for different representations too, e= ..g. with the URI template[]=A0being one of them.
=A0
Can we re-use the WebDAV collection model here? Web application authors

probably would prefer a JSON representation, so can we simply define
this as an alternate representation of a DAV:multistatus description of
a collection?

2) Define namespace operations in terms of manipulating collection
representations (also consider a mapping to COPY/MOVE).

3) Define a media type to use with PATCH for modifying these
representations.

4) Define a property model (something like the intersection between
WebDAV properties and Java Content Repository (JSR-283) properties?)


# Authoring through HTML forms and POST

Define how POST with multipart/form-data (RFC 2388) can be used for
authoring both content and properties.


# URIs for collection browsing

Assign either hardwired or discoverable URIs for inspecting collections
(URI templates?). Or maybe link relations for collection navigation
(similar work for versioning: RFC 5829).


# Improvements to WebDAV

1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this
question comes up quite frequently).

2) Define how to use POST on WebDAV collections to add members (done:
see http://greenbytes.de/tech/webdav/#draft-reschke-webdav-p= ost, in RFC
Editor queue).

3) Define media types (multiple?) for DAV:multistatus.

4) Define a discovery mechanism for GETtable representations of
PROPFIND/REPORT results (old proposal:
http://greenbytes.de/tech/webdav/draft-resc= hke-http-get-location-latest.html).

5) Define a mapping between link-typed WebDAV properties and generic
Link relations (see proposal:
http://lists.w3.org/Archives/Public/w3c-dist-auth= /2008OctDec/0026.html).

Although some of this will only be partially related to WebDAV, we think that this mailing list might be a good venue for discussion.


Expected deliverables from this activity would be:

1) Definition of a very simply data model and a representation format
for it (required JSON, optionally XML).

2) A format suitable for manipulating the data format above using PATCH
(potentially tunneled through POST).

3) A binding from multipart/form-data/POST to this model.

4) A separate (?) document explaining how these ingredients would be
combined in practice.

Extensions to WebDAV and mappings from/to WebDAV could be useful, but
would not be a core part of this activity. (That is, we can do without
if no volunteers speak up).

Resource-based concurrency-control and sync (= revision logs) specs may be developed on top of these deliverables as well.=
=A0

Note =A0that not all of these specs necessarily need to be on the
standards =A0track; for instance, there might be candidates for
Informational RFCs as =A0well (see
<http://tools.ietf.org/html/rfc2026#section-4> for details).


Feedback appreciated.

Julian Reschke
David N=FCscheler



PS: people not familiar with the IETF may want to have a look at
<http://www.i= etf.org/tao.html>




--0016361e89be89f1b5048dbb589d-- From webdav-archive@ietf.org Sun Aug 15 00:36:48 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09323A6872 for ; Sun, 15 Aug 2010 00:36:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -62.803 X-Spam-Level: X-Spam-Status: No, score=-62.803 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FB_GET_MEDS=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, MIME_8BIT_HEADER=0.3, RATWARE_MS_HASH=1.398, RATWARE_OUTLOOK_NONAME=2.171, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, 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 GYYyk5Abl7l0 for ; Sun, 15 Aug 2010 00:36:48 -0700 (PDT) Received: from 189-29-52-54-ac.cpe.vivax.com.br (189-29-52-54-ac.cpe.vivax.com.br [189.29.52.54]) by core3.amsl.com (Postfix) with SMTP id 7D7EC3A67DB for ; Sun, 15 Aug 2010 00:36:47 -0700 (PDT) Message-Id: <1f9f701cb3c33$8c8a1790$36341dbd@Pc04> To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org VIAGRA ® Official Seller -20% From: webdav-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Sun, 15 Aug 2010 00:36:47 -0700 (PDT) Dear webdav-archive@ietf.org Get ready to make her happy. Discount price store: ID94563 http://groups.yahoo.com/group/snrthjlvf/message We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From w3c-dist-auth-request@listhub.w3.org Sun Aug 15 03:35:50 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627923A67A7 for ; Sun, 15 Aug 2010 03:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.33 X-Spam-Level: X-Spam-Status: No, score=-7.33 tagged_above=-999 required=5 tests=[AWL=3.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8bpPW0R0Ftab for ; Sun, 15 Aug 2010 03:35:49 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 8B5B13A6784 for ; Sun, 15 Aug 2010 03:35:49 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OkaXm-0007qJ-9v for w3c-dist-auth-dist@listhub.w3.org; Sun, 15 Aug 2010 10:34:22 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OkaXl-0007oU-BI for w3c-dist-auth@listhub.w3.org; Sun, 15 Aug 2010 10:34:21 +0000 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OkaXj-0006XE-MH for w3c-dist-auth@w3.org; Sun, 15 Aug 2010 10:34:21 +0000 Received: (qmail invoked by alias); 15 Aug 2010 10:33:48 -0000 Received: from p508FE9F5.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.233.245] by mail.gmx.net (mp051) with SMTP; 15 Aug 2010 12:33:48 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+bLcgb24Sb3aDVohXsjjDabLZhEzs1dOwJVmaMox 7o5uJt2SGaLswP Message-ID: <4C67C27D.4050501@gmx.de> Date: Sun, 15 Aug 2010 12:33:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Geoffrey M Clemm CC: WebDAV , w3c-dist-auth-request@w3.org References: <4C63B2AB.6090701@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OkaXj-0006XE-MH 2be536059d80e30ad9f72a013be59b99 X-Original-To: w3c-dist-auth@w3.org Subject: payload formats and methods, was: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13300 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 15 Aug 2010 10:34:22 +0000 On 14.08.2010 03:58, Geoffrey M Clemm wrote: > One of the things I'd like to see with this work is to settle the > various syntax debates, by just defining mappings to a variety of syntaxes. > > One key part of this is already identified below, i.e. define a GET URI > scheme for any method that involves reading data. Right. I think if we do this right it might address the biggest shortcoming of WebDAV (the non-adressability of PROPFIND results, and its implications on every other part of HTTP, such as cacheing or range requests). > In addition, define a POST body syntax for any method that is not in > HTTP/1.1. Do you mean for non-read methods? From a consistency point of few that sounds logical. However, I'm not convinced it's needed; the main issue with extension methods nowadays seem to be with broken intermediaries, and that can be addressed by using https (which is often ok for authoring operations). If we did this, we probably would need to spec X-Method-Override (shudder). > Finally, define an AtomPub and JSON variant, in addition to the XML that > WebDAV would normally use. > > This would then allow us to focus on the semantics, and avoid all the > syntax debates. > And if a particular syntax has trouble expressing some of the semantics, > that would highlight why one syntax might be preferable to another. +1 Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Sun Aug 15 04:06:28 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EB43A6874 for ; Sun, 15 Aug 2010 04:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.393 X-Spam-Level: X-Spam-Status: No, score=-7.393 tagged_above=-999 required=5 tests=[AWL=3.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2fhVS5xm2WKP for ; Sun, 15 Aug 2010 04:06:26 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C744A3A685E for ; Sun, 15 Aug 2010 04:06:26 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Okb2j-0000Ke-7Y for w3c-dist-auth-dist@listhub.w3.org; Sun, 15 Aug 2010 11:06:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Okb2i-0000Ja-M0 for w3c-dist-auth@listhub.w3.org; Sun, 15 Aug 2010 11:06:20 +0000 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.69) (envelope-from ) id 1Okb2g-0004Be-LL for w3c-dist-auth@w3.org; Sun, 15 Aug 2010 11:06:20 +0000 Received: (qmail invoked by alias); 15 Aug 2010 11:05:44 -0000 Received: from p508FE9F5.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.233.245] by mail.gmx.net (mp002) with SMTP; 15 Aug 2010 13:05:44 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+rGvweh9+risyL6VR6aBX4pY+k7vCapAC/RZk/M6 GP7nMps6jb8eFp Message-ID: <4C67C9F3.2080705@gmx.de> Date: Sun, 15 Aug 2010 13:05:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jukka Zitting CC: WebDAV References: <4C63B2AB.6090701@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Okb2g-0004Be-LL 744eaa82ddd5a5edea6a8878b664d950 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13301 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 15 Aug 2010 11:06:21 +0000 On 12.08.2010 19:54, Jukka Zitting wrote: > Hi, > > On Thu, Aug 12, 2010 at 10:36 AM, Julian Reschke wrote: >> Proposal for work on an efficient, browser-friendly, HTTP-based >> communication protocol for fine-grained information exchange > > Sounds useful! See [1] for a few basic use cases and requirements I > outlined for such a protocol last year. It seems like the proposed > protocol could match these needs well, and I'd be eager to participate > in ironing out the details. See below for some initial comments. > > [1] http://jukkaz.wordpress.com/2009/11/18/content-repository-over-http/ Yes, that's a good read. When we wrote the proposal I had forgotten about it already, otherwise I would have stolen more from it :-) >> [... WebDAV / Atom(Pub) ...] >> Both of those protocol specifications are not easily consumed by websites >> and applications running current browsers and require a lot of client-sided >> scripting to cover simple read and write use cases. > > I'd add that also on server-side processing JSON or HTML forms is > usually easier than handling WebDAV or AtomPub. I think that depends entirely on libraries. For WebDAV, there are good libraries out there (Jackrabbit and WebDAV for JAX-RS come to mind). Actually, JAX-RS + the WebDAV extensions described in might be a nice prototyping environment for what we're doing. >> # Data Model >> >> 1) Define a collection model (hierarchy, naming), and a representation >> format. >> >> Can we re-use the WebDAV collection model here? Web application authors >> probably would prefer a JSON representation, so can we simply define this as >> an alternate representation of a DAV:multistatus description of a >> collection? > > It would be good if anything that can be expressed by this protocol > could be straightforwardly mapped to WebDAV and/or Atom. The reverse > does not need to be true, I'd rather go for simplicity than strive for > a full one-to-one mapping with another protocol. Yes. >> 4) Define a property model (something like the intersection between WebDAV >> properties and Java Content Repository (JSR-283) properties?) > > As above, I'd focus on core property types shared by existing standards. Indeed. We'll need to think about types (none, some, many?), cardinality, and naming. >> # URIs for collection browsing >> >> Assign either hardwired or discoverable URIs for inspecting collections (URI >> templates?). Or maybe link relations for collection navigation (similar work >> for versioning: RFC 5829). > > I'd rather avoid hardwiring URIs. +1; but it will make things slightly more complicated. > ... > Thanks! This was my first post here, so let me briefly introduce > myself: I've been working with open source content management since > -97 and for the past few years I've been focusing on Apache Jackrabbit > and other related Apache projects. I work for Day Software and have > participated in the JCR standardization effort in the JCP. I'm from > Finland, but currently based in Basel, Switzerland. > ... Welcome to the IETF (in case we decide to make this an IETF activity)! Otherwise, just welcome to this mailing list... :-) Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Sun Aug 15 05:11:53 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73483A690C for ; Sun, 15 Aug 2010 05:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.453 X-Spam-Level: X-Spam-Status: No, score=-7.453 tagged_above=-999 required=5 tests=[AWL=3.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ngKgLpPsPXVd for ; Sun, 15 Aug 2010 05:11:50 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 802073A68BC for ; Sun, 15 Aug 2010 05:11:49 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Okc3b-0003eA-K7 for w3c-dist-auth-dist@listhub.w3.org; Sun, 15 Aug 2010 12:11:19 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Okc3b-0003cz-09 for w3c-dist-auth@listhub.w3.org; Sun, 15 Aug 2010 12:11:19 +0000 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.69) (envelope-from ) id 1Okc3Z-0007VS-IT for w3c-dist-auth@w3.org; Sun, 15 Aug 2010 12:11:18 +0000 Received: (qmail invoked by alias); 15 Aug 2010 12:10:43 -0000 Received: from p508FE9F5.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.233.245] by mail.gmx.net (mp024) with SMTP; 15 Aug 2010 14:10:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+0McYTPvi0hdvucMvxzg8V7fHdzGjYls7ObUyJUt UJHvDIA/YNpsb5 Message-ID: <4C67D92A.4010505@gmx.de> Date: Sun, 15 Aug 2010 14:10:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Wenbo Zhu CC: w3c-dist-auth@w3.org References: <4C63C650.1090301@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Okc3Z-0007VS-IT 4c297c2e5443ac2a92d020ef59fa9885 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13302 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 15 Aug 2010 12:11:19 +0000 On 13.08.2010 10:02, Wenbo Zhu wrote: > ... > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation > format. > > I have seen many debates around representation formats when the > underlying meta-model is often ignored ... and the meta-model should > cover, in addition to hierarchy, relations. And naming should allow for > different representations too, e.g. with the URI template[] being one of > them. I think we need to be careful; if we over-engineer the data model we may scare away parts of the audience we want to include. It should be possible to define something that has an easy-to-use JSON representation but still have a solid model in the background. Including relations into the model makes sense to me. Links and link relations are important. I'm not sure I understand the point about naming; could you elaborate? > ... > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format > for it (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. > > Extensions to WebDAV and mappings from/to WebDAV could be useful, but > would not be a core part of this activity. (That is, we can do without > if no volunteers speak up). > > > Resource-based concurrency-control and sync (revision logs) specs may be > developed on top of these deliverables as well. Concurrency control as in locking? (be it optimistic or pessimistic) Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Sun Aug 15 05:27:43 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401753A68DE for ; Sun, 15 Aug 2010 05:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.511 X-Spam-Level: X-Spam-Status: No, score=-7.511 tagged_above=-999 required=5 tests=[AWL=3.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ld96rv15PDBV for ; Sun, 15 Aug 2010 05:27:42 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 3CC0D3A68B6 for ; Sun, 15 Aug 2010 05:27:42 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OkcJT-0000Xs-Ge for w3c-dist-auth-dist@listhub.w3.org; Sun, 15 Aug 2010 12:27:43 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OkcJS-0000Wn-Ul for w3c-dist-auth@listhub.w3.org; Sun, 15 Aug 2010 12:27:42 +0000 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by lisa.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OkcJR-00084u-Mp for w3c-dist-auth@w3.org; Sun, 15 Aug 2010 12:27:42 +0000 Received: (qmail invoked by alias); 15 Aug 2010 12:27:07 -0000 Received: from p508FE9F5.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.233.245] by mail.gmx.net (mp003) with SMTP; 15 Aug 2010 14:27:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18COZo39k8Caf6VRETLf1NEEBvApy8ohqDtjaXz07 xMzH9jjT87Hg6p Message-ID: <4C67DD07.4030304@gmx.de> Date: Sun, 15 Aug 2010 14:26:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Leigh L. Klotz, Jr" CC: w3c-dist-auth@w3.org References: <4C63C3DA.50809@gmx.de> <4C65848C.50504@xerox.com> In-Reply-To: <4C65848C.50504@xerox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1OkcJR-00084u-Mp 7059fa0a3ee20ef208b89cce50aa086e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Fwd: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13303 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 15 Aug 2010 12:27:43 +0000 On 13.08.2010 19:44, Leigh L. Klotz, Jr wrote: > [re-post from atom-protocol@mic.org at Julian's request] > > You might consider looking at multipart/related POST of XML (or JSON) > and document content data. Hm, in a browser, that requires client-side code that constructs the whole payload as a string, right? (Just clarifying) > An XForms binding would also be a good match, since XForms is designed > to be a REST client, and it has good support for structured XML data > such as Atom, and for POST and PUT of multipart/related data. > > XForms already has a high adoption rate in the CMS / ECM industry > already (our own product DocuShare, Documentum/EMC, Alfresco, Atlassian, > Nuxeo, SmartSite iXperion, MarkLogic, etc.) > > There are good, free JavaScript implementations of XForms (Ubiquity > XForms from IBM et al, XSLTForms from AgenceXML) and free server-side > ones as well (Orbeon, Betterforms, etc.). > > Not all of these free implementations support multipart/related POST of > XML with attached documents, but until browser support for MVC > frameworks gets better, you can define an alternate wire syntax using > multipart/form-data with one field containing a string of XML. A similar Personally, I'd love XForms to be a success. But I think we'd need to prove that it's actually easy to use on a client. It probably would be cool to look at some of David's examples and to describe how this would work with this approach. > approach has been used in old implementations of JavaScript's XHR which > don't support DELETE and PUT, by setting a well-known header to > communicate the real intent and using POST. I'm not sure that there ever was an XHR implementation not supporting DELETE and PUT (*); but as of today, they all do. Best regards, Julian (*) As opposed to DELETE and PUT from HTML forms, which is an entirely different story. From muweg7068@comcast.net Wed Aug 18 13:19:59 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE433A6846 for ; Wed, 18 Aug 2010 13:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.06 X-Spam-Level: X-Spam-Status: No, score=-44.06 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, MANGLED_HERBAL=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, 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 eNGxLR8dS350 for ; Wed, 18 Aug 2010 13:19:58 -0700 (PDT) Received: from comcast.net (c-98-231-27-104.hsd1.pa.comcast.net [98.231.27.104]) by core3.amsl.com (Postfix) with ESMTP id 8AD2F3A6A12 for ; Wed, 18 Aug 2010 13:19:58 -0700 (PDT) From: To: webdav-archive@ietf.org Reply-To: Subject: Free delivery for all herba1 purchases Date: Wed, 18 Aug 2010 16:20:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100818201958.8AD2F3A6A12@core3.amsl.com> She will not believe the pleasure you can bring to her http://www.booksolo.ru/ From webdav-archive@ietf.org Thu Aug 19 04:10:04 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEA63A681A for ; Thu, 19 Aug 2010 04:10:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -36.237 X-Spam-Level: X-Spam-Status: No, score=-36.237 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 mqgmnNwy7XHH for ; Thu, 19 Aug 2010 04:09:59 -0700 (PDT) Received: from 174.39.asx.dial.vsi.ru (174.39.asx.dial.vsi.ru [80.82.39.174]) by core3.amsl.com (Postfix) with ESMTP id 304B03A6816 for ; Thu, 19 Aug 2010 04:09:57 -0700 (PDT) Received: (qmail 2764 by uid 392); Thu, 19 Aug 2010 15:06:55 +0400 Message-Id: <20100819150655.2766.qmail@174.39.asx.dial.vsi.ru> From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org VIAGRA ® Official Seller -39% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 2010 04:09:57 -0700 (PDT)
Click here to view as a web page.

View image in browser now
To webdav-archive@ietf.org | Privacy Policy | Contact Us

Copyright © 2010 All rights reserved.
From w3c-dist-auth-request@listhub.w3.org Thu Aug 19 05:52:40 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E543A68D7 for ; Thu, 19 Aug 2010 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8] 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 XV8yzUdu0w1d for ; Thu, 19 Aug 2010 05:52:38 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 56C653A67F4 for ; Thu, 19 Aug 2010 05:52:38 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Om4am-0006R3-KV for w3c-dist-auth-dist@listhub.w3.org; Thu, 19 Aug 2010 12:51:36 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Om4al-0006PJ-GP for w3c-dist-auth@listhub.w3.org; Thu, 19 Aug 2010 12:51:35 +0000 Received: from jay.w3.org ([128.30.52.169]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Om4aj-0005sw-NV for w3c-dist-auth@w3.org; Thu, 19 Aug 2010 12:51:35 +0000 Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Om4aj-00055c-1X; Thu, 19 Aug 2010 08:51:33 -0400 Date: Thu, 19 Aug 2010 08:51:33 -0400 (EDT) From: Yves Lafon To: Julian Reschke cc: WebDAV In-Reply-To: <4C63B2AB.6090701@gmx.de> Message-ID: References: <4C63B2AB.6090701@gmx.de> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1Om4aj-0005sw-NV f4ad22f445833b0fd8b8ead7a08ebec0 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13304 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 19 Aug 2010 12:51:36 +0000 On Thu, 12 Aug 2010, Julian Reschke wrote: > Proposal for work on an efficient, browser-friendly, HTTP-based communica= tion=20 > protocol for fine-grained information exchange > > HTTP/1.1 (RFC 2616) already contains a set of tools for modifying resourc= es ,=20 > namely the methods PUT, POST, and DELETE. > > Many systems have been built on top of this, most of them in an ad-hoc ma= nner=20 > (which is ok when client and server are controlled by the same developers= ). > > We would like to cover some of the following use cases extending the reso= urce=20 > oriented model. > > (1) An simple javascript based browser application should be able to read= =20 > fine-grained information (comparable to WebDAV properties) in a simple ma= nner=20 > using a defined JSON format to be consumed in an intuitive fashion. > > (2) A simple HTML Form should be able to write information in a patch=20 > oriented manner containing both binary (file) data and fine-grained, type= d=20 > information using a multipart POST. > > (3) A simple javascript application should be able to write information i= n a=20 > patch oriented fashion using a defined JSON-diff PATCH content-type to up= date=20 > fine-grained information. > > There are also several extensions/applications of HTTP in this space, suc= h=20 > as: > > - WebDAV (RFC 4918), which defines (a) a collection model and methods to= =20 > manipulate collections/namespaces, (b) a metadata (=3Dproperty) model, an= d (c)=20 > locking. Other RFCs add extensions on top of this, such as Versioning (RF= C=20 > 3253) and ACLs (RFC 3744). > > - The Atom feed format (RFC 4287) and AtomPub (RFC 5023) use a simpler, n= ot=20 > necessarily hierarchic collection model (which, depending on the use case= ,=20 > may be a plus), but does not provide many features WebDAV + friends defin= e.=20 > Notably, namespace operations are absent. It seems that there are two main uses cases here, the first one is to replace WebDAV's way of handling metadata on a resource, and the second one goes into the service/data discovery space. Would it be better to divide clearly the tasks along those lines ? Also, at that point, the format (JSON) is irrelevant, the data format should come after defining the goals, and the protocol bits. XFORMS has=20 been mentionned, but once again it is premature, and this discussion=20 should take place after figuring out the right interactions needed. For service discovery, well-known URIs is a possibility, especially for services "on the server", but it might also be useful to to this via Link: (like a Printer Resource claiming that it can be contacted via IPP,=20 without having to contact a wkURI first), so extending the scope would=20 be good. > > Both of those protocol specifications are not easily consumed by websites= and=20 > applications running current browsers and require a lot of client-sided= =20 > scripting to cover simple read and write use cases. > > There's a proposal for a protocol called "JSOP", which addresses these us= e=20 > cases, which we may want to consider as input for this work:=20 > > > So what's wrong with WebDAV? > > Since the time WebDAV was designed, we have learned a lot how to use the = Web=20 > and HTTP. Such as: > > - if you want to expose data for read operations, make it available to GE= T,=20 > and assign URIs, > > - consider cacheability, atomicity, and performance of sync operations (f= or=20 > instance, syncing large collections), > > - be careful with new HTTP methods -- avoid them for things that are not = of=20 > generic use (good: MKCOL, bad: MKCALENDAR) and keep in mind that certain= =20 > platforms (HTML forms, Flash...) can't use them, > > - when defining formats, also define internet media types. > > Also, in the last few months, new (and not so new) techniques have finall= y=20 > been published as RFCs, such as: > > - HTTP PATCH method (RFC 5789) > > - HTTP Link Header and Link Relations Registry=20 > (http://tools.ietf.org/html/draft-nottingham-http-link-header-10, in the = RFC=20 > Editor queue) > > - Service Discovery through well-known URIs (RFC 5785) > > Another potential building block are URI templates (work in progress:=20 > http://tools.ietf.org/html/draft-gregorio-uritemplate-04) > > Considering all of these pieces, it's quite obvious that there's a number= of=20 > specs that would be useful on their own, but could also, combined togethe= r,=20 > form the basis of an interesting authoring protocol: > > > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation=20 > format. > > Can we re-use the WebDAV collection model here? Web application authors= =20 > probably would prefer a JSON representation, so can we simply define this= as=20 > an alternate representation of a DAV:multistatus description of a collect= ion? > > 2) Define namespace operations in terms of manipulating collection=20 > representations (also consider a mapping to COPY/MOVE). > > 3) Define a media type to use with PATCH for modifying these representati= ons. > > 4) Define a property model (something like the intersection between WebDA= V=20 > properties and Java Content Repository (JSR-283) properties?) > > > # Authoring through HTML forms and POST > > Define how POST with multipart/form-data (RFC 2388) can be used for autho= ring=20 > both content and properties. > > > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collections (= URI=20 > templates?). Or maybe link relations for collection navigation (similar w= ork=20 > for versioning: RFC 5829). > > > # Improvements to WebDAV > > 1) Clarify how MOVE and COPY can operate on non-WebDAV resources (this=20 > question comes up quite frequently). > > 2) Define how to use POST on WebDAV collections to add members (done: see= =20 > http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post, in RFC Edito= r=20 > queue). > > 3) Define media types (multiple?) for DAV:multistatus. > > 4) Define a discovery mechanism for GETtable representations of=20 > PROPFIND/REPORT results (old proposal:=20 > http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.h= tml). > > 5) Define a mapping between link-typed WebDAV properties and generic Link= =20 > relations (see proposal:=20 > http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html). > > Although some of this will only be partially related to WebDAV, we think = that=20 > this mailing list might be a good venue for discussion. > > > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format for= it=20 > (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH= =20 > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be comb= ined=20 > in practice. > > Extensions to WebDAV and mappings from/to WebDAV could be useful, but wou= ld=20 > not be a core part of this activity. (That is, we can do without if no=20 > volunteers speak up). > > Note that not all of these specs necessarily need to be on the standards= =20 > track; for instance, there might be candidates for Informational RFCs as= =20 > well (see for details). > > > Feedback appreciated. > > Julian Reschke > David N=FCscheler > > > > PS: people not familiar with the IETF may want to have a look at=20 > > > > --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From webdav-archive@lists.ietf.org Thu Aug 19 11:14:11 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762163A67FD for ; Thu, 19 Aug 2010 11:14:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...ve@lists.ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -6.694 X-Spam-Level: X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 QKI7sfRU6qEh for ; Thu, 19 Aug 2010 11:14:04 -0700 (PDT) Received: from ip2-146-111-78.pppoe.ivanovo.stream.ru (ip2-146-111-78.pppoe.ivanovo.stream.ru [78.111.146.2]) by core3.amsl.com (Postfix) with ESMTP id CEBB93A686A for ; Thu, 19 Aug 2010 11:14:02 -0700 (PDT) Received: (qmail 2788 by uid 428); Thu, 19 Aug 2010 22:14:03 +0400 Message-Id: <20100819181436.2946.qmail@ip2-146-111-78.pppoe.ivanovo.stream.ru> From: webdav-archive@lists.ietf.org To: webdav-archive@lists.ietf.org Subject: webdav-archive@lists.ietf.org VIAGRA ® Official Seller -09% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 2010 11:14:02 -0700 (PDT)
Click here to view as a web page.

View image in browser now
To webdav-archive@lists.ietf.org | Privacy Policy | Contact Us

Copyright © 2010 All rights reserved.
From webdav-archive@ietf.org Thu Aug 19 11:14:12 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79803A6844 for ; Thu, 19 Aug 2010 11:14:12 -0700 (PDT) X-Quarantine-ID: <5e7t+tmAsOk3> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -6.694 X-Spam-Level: X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 5e7t+tmAsOk3 for ; Thu, 19 Aug 2010 11:14:04 -0700 (PDT) Received: from ip2-146-111-78.pppoe.ivanovo.stream.ru (ip2-146-111-78.pppoe.ivanovo.stream.ru [78.111.146.2]) by core3.amsl.com (Postfix) with ESMTP id CEBD33A6899 for ; Thu, 19 Aug 2010 11:14:02 -0700 (PDT) Received: (qmail 2788 by uid 428); Thu, 19 Aug 2010 22:14:03 +0400 Message-Id: <20100819181436.2708.qmail@ip2-146-111-78.pppoe.ivanovo.stream.ru> From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org VIAGRA ® Official Seller -09% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 2010 11:14:02 -0700 (PDT)
Click here to view as a web page.

View image in browser now
To webdav-archive@ietf.org | Privacy Policy | Contact Us

Copyright © 2010 All rights reserved.
From webdav-archive@megatron.ietf.org Thu Aug 19 11:19:20 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAF03A6847 for ; Thu, 19 Aug 2010 11:19:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...megatron.ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -6.694 X-Spam-Level: X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 eGLfpxvcrFKD for ; Thu, 19 Aug 2010 11:19:07 -0700 (PDT) Received: from ip2-146-111-78.pppoe.ivanovo.stream.ru (ip2-146-111-78.pppoe.ivanovo.stream.ru [78.111.146.2]) by core3.amsl.com (Postfix) with ESMTP id 2AC6D3A686C for ; Thu, 19 Aug 2010 11:19:04 -0700 (PDT) Received: (qmail 2788 by uid 428); Thu, 19 Aug 2010 22:14:03 +0400 Message-Id: <20100819181939.2096.qmail@ip2-146-111-78.pppoe.ivanovo.stream.ru> From: webdav-archive@megatron.ietf.org To: webdav-archive@megatron.ietf.org Subject: webdav-archive@megatron.ietf.org VIAGRA ® Official Seller -09% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 2010 11:19:04 -0700 (PDT)
Click here to view as a web page.

View image in browser now
To webdav-archive@megatron.ietf.org | Privacy Policy | Contact Us

Copyright © 2010 All rights reserved.
From w3c-dist-auth-request@listhub.w3.org Thu Aug 19 12:38:23 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345743A6A72 for ; Thu, 19 Aug 2010 12:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.976 X-Spam-Level: X-Spam-Status: No, score=-7.976 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 QJQlUaCH-di2 for ; Thu, 19 Aug 2010 12:38:19 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id BAADF3A69E9 for ; Thu, 19 Aug 2010 12:37:57 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OmAtH-00088v-3g for w3c-dist-auth-dist@listhub.w3.org; Thu, 19 Aug 2010 19:35:07 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OmAGP-00084q-7l for w3c-dist-auth@listhub.w3.org; Thu, 19 Aug 2010 18:54:57 +0000 Received: from smtp-out.google.com ([74.125.121.35]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Om9Qb-0005rp-Fh for w3c-dist-auth@w3.org; Thu, 19 Aug 2010 18:01:26 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o7JI0xK5008027 for ; Thu, 19 Aug 2010 11:00:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282240859; bh=3GcL7QLxwsdScmBlSV3aI/jys6k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=HpwQ8ENcUk7nUgr9C3QCFojrBfBGoeROlrjYCugg9Xjoh6aQx5dmvxfhMDmKfQiNo xH2IpisfheirGs+nY/40w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=w5iFm/VXUJCP4eUWxjJUj9p3c+vGOJgz2IxH9tZ+HY48rMcOT6+56GFrPWoBrFWMn c1Q+v2jnRPy9DPyujhnJg== Received: from gwb1 (gwb1.prod.google.com [10.200.2.1]) by wpaz1.hot.corp.google.com with ESMTP id o7JHxwaR029561 for ; Thu, 19 Aug 2010 11:00:58 -0700 Received: by gwb1 with SMTP id 1so1278316gwb.40 for ; Thu, 19 Aug 2010 11:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.49.2 with SMTP id w2mr363647agw.120.1282240858032; Thu, 19 Aug 2010 11:00:58 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Thu, 19 Aug 2010 11:00:57 -0700 (PDT) In-Reply-To: <4C67D92A.4010505@gmx.de> References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> Date: Thu, 19 Aug 2010 11:00:57 -0700 Message-ID: From: Wenbo Zhu To: Julian Reschke Cc: w3c-dist-auth@w3.org Content-Type: multipart/alternative; boundary=00163630f4e5dc0e3d048e30f632 X-System-Of-Record: true Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, DKIM_SIGNED=0.001, DKIM_VERIFIED=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Om9Qb-0005rp-Fh 0ef9f9de2502f0b030c902a14c72776e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13305 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 19 Aug 2010 19:35:07 +0000 --00163630f4e5dc0e3d048e30f632 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 15, 2010 at 5:10 AM, Julian Reschke wrote: > On 13.08.2010 10:02, Wenbo Zhu wrote: > >> ... >> >> # Data Model >> >> 1) Define a collection model (hierarchy, naming), and a representation >> format. >> >> I have seen many debates around representation formats when the >> underlying meta-model is often ignored ... and the meta-model should >> cover, in addition to hierarchy, relations. And naming should allow for >> different representations too, e.g. with the URI template[] being one of >> them. >> > > I think we need to be careful; if we over-engineer the data model we may > scare away parts of the audience we want to include. It should be possible > to define something that has an easy-to-use JSON representation but still > have a solid model in the background. > > Including relations into the model makes sense to me. Links and link > relations are important. > > I'm not sure I understand the point about naming; could you elaborate? > Separate the logic naming scheme from its syntactic representation ... and the former should be derived from the "background model". When relationships are included, entities may be addressed via links too. > > ... >> >> Expected deliverables from this activity would be: >> >> 1) Definition of a very simply data model and a representation format >> for it (required JSON, optionally XML). >> >> 2) A format suitable for manipulating the data format above using PATCH >> (potentially tunneled through POST). >> >> 3) A binding from multipart/form-data/POST to this model. >> >> 4) A separate (?) document explaining how these ingredients would be >> combined in practice. >> >> Extensions to WebDAV and mappings from/to WebDAV could be useful, but >> would not be a core part of this activity. (That is, we can do without >> if no volunteers speak up). >> >> >> Resource-based concurrency-control and sync (revision logs) specs may be >> developed on top of these deliverables as well. >> > > Concurrency control as in locking? (be it optimistic or pessimistic) > Yes. > > Best regards, Julian > --00163630f4e5dc0e3d048e30f632 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Aug 15, 2010 at 5:10 AM, Julian = Reschke <juli= an.reschke@gmx.de> wrote:
On 13.08.2010 10:02, Wenbo Zhu wrote:
...

=A0 =A0# Data Model

=A0 =A01) Define a collection model (hierarchy, naming), and a representat= ion
=A0 =A0format.

I have seen many debates around representation formats when the
underlying meta-model is often ignored ... and the meta-model should
cover, in addition to hierarchy, relations. And naming should allow for
different representations too, e.g. with the URI template[] being one of them.

I think we need to be careful; if we over-engineer the data model we may sc= are away parts of the audience we want to include. It should be possible to= define something that has an easy-to-use JSON representation but still hav= e a solid model in the background.

Including relations into the model makes sense to me. Links and link relati= ons are important.

I'm not sure I understand the point about naming; could you elaborate?<= br>
Separate the logic naming scheme from its syntactic re= presentation ... =A0and the former should be derived from the "backgro= und model". When relationships are included, entities may be addressed= via links too.

=A0

...

=A0 =A0Expected deliverables from this activity would be:

=A0 =A01) Definition of a very simply data model and a representation form= at
=A0 =A0for it (required JSON, optionally XML).

=A0 =A02) A format suitable for manipulating the data format above using P= ATCH
=A0 =A0(potentially tunneled through POST).

=A0 =A03) A binding from multipart/form-data/POST to this model.

=A0 =A04) A separate (?) document explaining how these ingredients would b= e
=A0 =A0combined in practice.

=A0 =A0Extensions to WebDAV and mappings from/to WebDAV could be useful, b= ut
=A0 =A0would not be a core part of this activity. (That is, we can do with= out
=A0 =A0if no volunteers speak up).


Resource-based concurrency-control and sync (revision logs) specs may be developed on top of these deliverables as well.

Concurrency control as in locking? (be it optimistic or pessimistic)
Yes.
=A0

Best regards, Julian

--00163630f4e5dc0e3d048e30f632-- From yduxuw7762@comcast.net Thu Aug 19 12:40:29 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B46F3A659C for ; Thu, 19 Aug 2010 12:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.941 X-Spam-Level: X-Spam-Status: No, score=-13.941 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HOST_EQ_D_D_D_D=0.765, MANGLED_HERBAL=2.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 oMDtWRjtbt9L for ; Thu, 19 Aug 2010 12:40:28 -0700 (PDT) Received: from comcast.net (c-75-74-1-149.hsd1.fl.comcast.net [75.74.1.149]) by core3.amsl.com (Postfix) with ESMTP id 5889B3A67D4 for ; Thu, 19 Aug 2010 12:40:28 -0700 (PDT) Date: Thu, 19 Aug 2010 15:41:03 -0400 To: webdav-archive@ietf.org From: Reply-To: Subject: 50% more length with herba1 formula MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100819194028.5889B3A67D4@core3.amsl.com> Making women come is as easy as 1-2-3 once you are longer than 7. http://www.messagesled.ru/ From webdav-archive@ietf.org Fri Aug 20 11:55:11 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8578A3A6972 for ; Fri, 20 Aug 2010 11:55:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: USA VIAGRA \256 Official ; Fri, 20 Aug 2010 11:55:10 -0700 (PDT) Received: from dialup-115.nas02.azerin.com (dialup-115.nas02.azerin.com [212.47.133.115]) by core3.amsl.com (Postfix) with SMTP id D5E203A68B5 for ; Fri, 20 Aug 2010 11:55:00 -0700 (PDT) From: USA VIAGRA ® Official To: webdav-archive@ietf.org Subject: Dear webdav-archive@ietf.org 62% 0FF on Pfizer!!! MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100820185502.D5E203A68B5@core3.amsl.com> Date: Fri, 20 Aug 2010 11:55:00 -0700 (PDT) Dear webdav-archive@ietf.org! Get ready to make her happy. Discount price store: ID11405937 http://groups.yahoo.com/group/ilsmcs/message We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From w3c-dist-auth-request@listhub.w3.org Sun Aug 22 08:10:57 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39E63A68CD for ; Sun, 22 Aug 2010 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.82 X-Spam-Level: X-Spam-Status: No, score=-6.82 tagged_above=-999 required=5 tests=[AWL=2.290, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] 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 pKoCc6JFqVIB for ; Sun, 22 Aug 2010 08:10:54 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 05F193A68B9 for ; Sun, 22 Aug 2010 08:10:51 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OnCAT-00077w-UH for w3c-dist-auth-dist@listhub.w3.org; Sun, 22 Aug 2010 15:09:05 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OnCAS-00076r-Od for w3c-dist-auth@listhub.w3.org; Sun, 22 Aug 2010 15:09:04 +0000 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OnCAQ-0001xa-TD for w3c-dist-auth@w3.org; Sun, 22 Aug 2010 15:09:04 +0000 Received: (qmail invoked by alias); 22 Aug 2010 15:08:30 -0000 Received: from p508FC2D3.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.194.211] by mail.gmx.net (mp063) with SMTP; 22 Aug 2010 17:08:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/neiNgpV7n2pPNjVWAfnnvEJZujVLJZYkaUXxFby sCa+YZDjQ9N16l Message-ID: <4C713D5E.6050400@gmx.de> Date: Sun, 22 Aug 2010 17:08:14 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Wenbo Zhu CC: w3c-dist-auth@w3.org References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OnCAQ-0001xa-TD 4f897854db799cbb6af231755b95217b X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13306 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 22 Aug 2010 15:09:05 +0000 On 19.08.2010 20:00, Wenbo Zhu wrote: > I think we need to be careful; if we over-engineer the data model we > may scare away parts of the audience we want to include. It should > be possible to define something that has an easy-to-use JSON > representation but still have a solid model in the background. > > Including relations into the model makes sense to me. Links and link > relations are important. > > I'm not sure I understand the point about naming; could you elaborate? > > Separate the logic naming scheme from its syntactic representation ... > and the former should be derived from the "background model". When Yes. We just need to make sure that by doing it this way, the wire format doesn't get more complicated than necessary. > relationships are included, entities may be addressed via links too. > Extensions to WebDAV and mappings from/to WebDAV could be > useful, but > would not be a core part of this activity. (That is, we can > do without > if no volunteers speak up). > > > Resource-based concurrency-control and sync (revision logs) > specs may be > developed on top of these deliverables as well. > > > Concurrency control as in locking? (be it optimistic or pessimistic) > > Yes. I think if we do things right, optimistic locking based on HTTP/1.1 conditional requests and etags will work. I'm not convinced there's big interest for pessimistic locking (à la WebDAV locking) at this point of time. Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Tue Aug 24 00:49:47 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95A43A6862 for ; Tue, 24 Aug 2010 00:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.377 X-Spam-Level: X-Spam-Status: No, score=-7.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8] 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 CPa4IXIySc8I for ; Tue, 24 Aug 2010 00:49:46 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2B4663A6875 for ; Tue, 24 Aug 2010 00:49:46 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OnoFR-0001gD-TJ for w3c-dist-auth-dist@listhub.w3.org; Tue, 24 Aug 2010 07:48:45 +0000 Received: from wiggum.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OnoFP-0001cE-N1 for w3c-dist-auth@listhub.w3.org; Tue, 24 Aug 2010 07:48:43 +0000 Received: from nobody by wiggum.w3.org with local (Exim 4.63) (envelope-from ) id 1OnoFP-0006pW-Nr for w3c-dist-auth@listhub.w3.org; Tue, 24 Aug 2010 07:48:43 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OnXYh-0008HW-IK for w3c-dist-auth@listhub.w3.org; Mon, 23 Aug 2010 13:59:31 +0000 Received: from eu3sys201aog103.obsmtp.com ([207.126.148.89]) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OnXYe-0004F6-OU for w3c-dist-auth@w3.org; Mon, 23 Aug 2010 13:59:31 +0000 Received: from source ([209.85.216.44]) by eu3sys201aob103.postini.com ([207.126.154.11]) with SMTP ID DSNKTHJ+pILf+/X4Faq0hmZobYJJDOrhYzCn@postini.com; Mon, 23 Aug 2010 13:59:28 UTC Received: by qwc9 with SMTP id 9so5575085qwc.31 for ; Mon, 23 Aug 2010 06:58:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.223.210 with SMTP id il18mr2477833qcb.133.1282571939433; Mon, 23 Aug 2010 06:58:59 -0700 (PDT) Received: by 10.229.220.134 with HTTP; Mon, 23 Aug 2010 06:58:58 -0700 (PDT) In-Reply-To: <4C713D5E.6050400@gmx.de> References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> Date: Mon, 23 Aug 2010 15:58:58 +0200 Message-ID: From: David Nuescheler To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OnXYe-0004F6-OU fb4568091371a00349935de1111e84df X-caa-id: 9329a86347917ad7e97e X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13307 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Tue, 24 Aug 2010 07:48:45 +0000 Hi All, Julian and I (and occasionally many others) have been discussing a development effort like this for quite while. I was involved in mapping the scope of WebDAV (and friends) into a Java API called JCR[1][2][3] (on which for example Geoff, Julian and Roy participated) and due to my Day[4] job (pun intended) I find myself very often in a situation where I need have a standard web-browser or client-sided web-application interact with a server to exchange fine-grained information. Thanks a lot to everybody for all the comments and input. I guess my main take from this is that I completely agree that we need to separate the "model"-conversation from the "format/binding"-conversation. I would like to mention though that in my mind the goal of making this effort relevant, efficient and simple is extremely important as well. While I appreciate that the separation of the discussions, I would like to volunteer to work on bindings to a JSON + PATCH (multipart POST) very early on in the process and keep it in sync with the model as a living set of examples for the interaction with the more abstract model, to ensure that we keep things practical. I think there are of a large number of very similar, JSON/POST-based "protocols" that are defined in an ad-hoc manner by developers. So there should be quite a bit of experience out there, that can help us gauge the importance some of requirements fairly quickly. I think if we manage to take the combined the experience from WebDAV, AtomPub and JCR (and possibly more domain specific efforts like CMIS) in terms of the overall scope and the initial relevance of certain features we should be in great shape. regards, david [1] http://jcp.org/en/jsr/detail?id=3D170 [2] http://jcp.org/en/jsr/detail?id=3D283 [3] http://jcp.org/en/jsr/detail?id=3D333 [4] http://www.day.com --=20 David Nuescheler Chief Technology Officer mailto: david.nuescheler@day.com web:=A0 http://www.day.com/ http://dev.day.com twitter: @davidnuescheler From igocypaxu5055@comcast.net Tue Aug 24 07:29:31 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA2D3A6AFC for ; Tue, 24 Aug 2010 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.259 X-Spam-Level: **** X-Spam-Status: No, score=4.259 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 wWOg0dbpCQ3Y for ; Tue, 24 Aug 2010 07:29:30 -0700 (PDT) Received: from comcast.net (c-68-62-55-179.hsd1.mi.comcast.net [68.62.55.179]) by core3.amsl.com (Postfix) with ESMTP id 997643A687C for ; Tue, 24 Aug 2010 07:29:30 -0700 (PDT) Date: Tue, 24 Aug 2010 10:30:06 -0400 To: webdav-archive@ietf.org From: Reply-To: Subject: Power in your pants MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100824142930.997643A687C@core3.amsl.com> Dream of her every night, take her down with an improved potion. http://www.armham.ru/ From w3c-dist-auth-request@listhub.w3.org Thu Aug 26 02:00:37 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1066B3A67C3 for ; Thu, 26 Aug 2010 02:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] 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 TpHPC36E0hPK for ; Thu, 26 Aug 2010 02:00:34 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 1C16F3A6862 for ; Thu, 26 Aug 2010 02:00:34 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OoYIy-00025o-VC for w3c-dist-auth-dist@listhub.w3.org; Thu, 26 Aug 2010 08:59:28 +0000 Received: from wiggum.w3.org ([128.30.52.43]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OoYIx-00024C-UL for w3c-dist-auth@listhub.w3.org; Thu, 26 Aug 2010 08:59:27 +0000 Received: from nobody by wiggum.w3.org with local (Exim 4.63) (envelope-from ) id 1OoYIx-0006Gk-OU for w3c-dist-auth@listhub.w3.org; Thu, 26 Aug 2010 08:59:27 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OoYCe-0000Ep-FQ for w3c-dist-auth@listhub.w3.org; Thu, 26 Aug 2010 08:52:56 +0000 Received: from gate.wyona.com ([195.226.6.75] helo=server1.example.com) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OoYCb-0007Se-LQ for w3c-dist-auth@w3.org; Thu, 26 Aug 2010 08:52:56 +0000 Received: from tg-10209.gallery.tate.org.uk (83-244-224-98.cust-83.exponential-e.net [83.244.224.98]) by server1.example.com (Postfix) with ESMTP id A06E610CDC0; Thu, 26 Aug 2010 10:52:33 +0200 (CEST) Message-ID: <4C762B47.2010205@wyona.com> Date: Thu, 26 Aug 2010 09:52:23 +0100 From: Michael Wechner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: David Nuescheler CC: w3c-dist-auth@w3.org References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1OoYCb-0007Se-LQ cb83bad4fa8619b0fa2597eb5dba9838 X-caa-id: 7c6f3f8eb2d4a457b9a2 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13308 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Thu, 26 Aug 2010 08:59:28 +0000 David Nuescheler wrote: > Hi All, > > Julian and I (and occasionally many others) have been discussing a > development effort like this for quite while. > I was involved in mapping the scope of WebDAV (and friends) into a > Java API called JCR[1][2][3] (on which for example Geoff, Julian and > Roy participated) and due to my Day[4] job (pun intended) I find > myself very often in a situation where I need have a standard > web-browser or client-sided web-application interact with a server to > exchange fine-grained information. > can you give a "real-world" example such that I can understand better :-) ? And also where the existing "protocols" are lacking? Thanks Michael > Thanks a lot to everybody for all the comments and input. > > I guess my main take from this is that I completely agree that we need > to separate the "model"-conversation from the > "format/binding"-conversation. > > I would like to mention though that in my mind the goal of making this > effort relevant, efficient and simple is extremely important as well. > While I appreciate that the separation of the discussions, I would > like to volunteer to work on bindings to a JSON + PATCH (multipart > POST) very early on in the process and keep it in sync with the model > as a living set of examples for the interaction with the more abstract > model, to ensure that we keep things practical. > > I think there are of a large number of very similar, JSON/POST-based > "protocols" that are defined in an ad-hoc manner by developers. So > there should be quite a bit of experience out there, that can help us > gauge the importance some of requirements fairly quickly. I think if > we manage to take the combined the experience from WebDAV, AtomPub and > JCR (and possibly more domain specific efforts like CMIS) in terms of > the overall scope and the initial relevance of certain features we > should be in great shape. > > regards, > david > > [1] http://jcp.org/en/jsr/detail?id=170 > [2] http://jcp.org/en/jsr/detail?id=283 > [3] http://jcp.org/en/jsr/detail?id=333 > [4] http://www.day.com > > From vomidyv2037@comcast.net Thu Aug 26 12:31:45 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7919D3A6AB2 for ; Thu, 26 Aug 2010 12:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.806 X-Spam-Level: X-Spam-Status: No, score=-11.806 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FB_EXTRA_INCHES=3.852, FH_HOST_EQ_D_D_D_D=0.765, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 FpCocznWWpvG for ; Thu, 26 Aug 2010 12:31:08 -0700 (PDT) Received: from comcast.net (c-76-16-166-59.hsd1.il.comcast.net [76.16.166.59]) by core3.amsl.com (Postfix) with ESMTP id E41973A68EF for ; Thu, 26 Aug 2010 12:30:35 -0700 (PDT) Date: Thu, 26 Aug 2010 14:31:12 -0500 To: webdav-archive@ietf.org From: Reply-To: Subject: Give you lady only the best MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100826193035.E41973A68EF@core3.amsl.com> Its time to reward yourself by getting that extra inches to your joystick. http://www.saltham.ru/ From w3c-dist-auth-request@listhub.w3.org Fri Aug 27 07:22:10 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A099A3A6961 for ; Fri, 27 Aug 2010 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.654 X-Spam-Level: X-Spam-Status: No, score=-8.654 tagged_above=-999 required=5 tests=[AWL=1.945, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 501vl9b+y3rp for ; Fri, 27 Aug 2010 07:22:09 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id AC5E83A683A for ; Fri, 27 Aug 2010 07:22:09 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OoznY-0002WE-0S for w3c-dist-auth-dist@listhub.w3.org; Fri, 27 Aug 2010 14:20:52 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OoznW-0002V9-QA for w3c-dist-auth@listhub.w3.org; Fri, 27 Aug 2010 14:20:50 +0000 Received: from mailout-de.gmx.net ([213.165.64.22] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OoznV-0007YC-4o for w3c-dist-auth@w3.org; Fri, 27 Aug 2010 14:20:50 +0000 Received: (qmail invoked by alias); 27 Aug 2010 14:20:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.147]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 27 Aug 2010 16:20:17 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19kq2gftPJko43baJnNkAVJoTAgVefGnMM8s4/CnN lUC+iDhlHJzD6a Message-ID: <4C77C991.5080700@gmx.de> Date: Fri, 27 Aug 2010 16:20:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Nuescheler CC: w3c-dist-auth@w3.org References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OoznV-0007YC-4o 7408a20b4cedb8f590db768da418bab1 X-Original-To: w3c-dist-auth@w3.org Subject: Data Model Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13309 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 27 Aug 2010 14:20:52 +0000 On 23.08.2010 15:58, David Nuescheler wrote: > ... > I guess my main take from this is that I completely agree that we need > to separate the "model"-conversation from the > "format/binding"-conversation. > ... Ok, here's a list of things we need to consider (probably incomplete, feel free to add) 1. Collections 1.1 Hierarchy: WebDAV collections are hierarchical. A "direct" member of a collection has the parent collections URI + one additional path segment. JCR same. This also means that relative paths do the obvious thing. CMIS/AtomPub: no constraints on the paths (AFAIU). 1.2 Multiple containment: allowed in WebDAV through multiple bindings, in JCR through shared nodes. CMIS/AtomPub: not constrained anyway. 1.3 Identification: WebDAV: the same of a resource within a collection is a unique identifier. JCR: same (except that for same-name-siblings, the array index may change when siblings are removed). 1.4 Ordering: optional features in WebDAV and JCR. 1.5 Member naming: in WebDAV by path segment (URI syntax), in JCR per optional namespace name + path segment. 1.6 Name encoding: in WebDAV per spec ASCII (+ URI percent encoding), in JCR Unicode. 2. Properties 2.1 Cardinality: properties can only occur once on a resource, but there are ways to express lists (WebDAV, JCR) 2.2 Typing: optional in WebDAV (see RFC 4316). Set of predefined types in JCR (int, float, string, date, URI, ...) 2.3 Naming: namespace name + local name (WebDAV, JCR) 3. Content 3.1 A single binary stream per HTTP in WebDAV (ignoring content negotiation for now which is tricky in authoring); modeled as binary property in JCR (with only conventions on naming) Best regards, Julian From osusitezuc6509@comcast.net Fri Aug 27 08:37:57 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194A33A69CA for ; Fri, 27 Aug 2010 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.407 X-Spam-Level: X-Spam-Status: No, score=-17.407 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 fGX+Si6n5OFs for ; Fri, 27 Aug 2010 08:37:56 -0700 (PDT) Received: from comcast.net (c-69-253-170-21.hsd1.nj.comcast.net [69.253.170.21]) by core3.amsl.com (Postfix) with ESMTP id CE4A73A687B for ; Fri, 27 Aug 2010 08:37:54 -0700 (PDT) Date: Fri, 27 Aug 2010 11:38:40 -0400 To: webdav-archive@ietf.org From: Reply-To: Subject: Men are prone to love dysfunction MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100827153755.CE4A73A687B@core3.amsl.com> Crazy in love with your girl, you need to make things more pleasurable for her. http://www.sickbulb.ru/ Open from May to October, the museum offers guided tours of the period rooms and hosts a variety of regular events to interpret the house and its gardens for families and children. Raby, P (2005) "Porsche 911 Identification Guide". Portuguese colonization of the Americas. After its adoption, four more states voted to ratify the amendment. The Marine Conservation Society has 5 levels of ratings for seafood species, as displayed on their Fishonline website. In judgments of morality and fairness. Immigration from outside the United States resulted in a net increase of 192,099 people, and migration within the country produced a net gain of 591,283 people. Emigration rates to Turkey," one analyst said, "are so high that most of the residents of the Besler district in Istanbul are Nakhchivanis. German is thus considered a pluricentric language. It may not present a worldwide view of the subject. The offices of the comune are housed in a building usually called the Municipio, or Palazzo Comunale. Lesser spotted Dogfish Scyliorhinus canicula. This letter, and other communications from the New York Congress, combined with the activities of vocal American supporters, stirred up the Quebec population in the summer of 1775. From webdate.horny@hermanbeun.nl Fri Aug 27 09:49:52 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A603A69AA for ; Fri, 27 Aug 2010 09:49:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -18.087 X-Spam-Level: X-Spam-Status: No, score=-18.087 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FUZZY_VPILL=0.687, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 wkRg8C3-cbrw for ; Fri, 27 Aug 2010 09:49:51 -0700 (PDT) Received: from e180223174.adsl.alicedsl.de (e180223174.adsl.alicedsl.de [85.180.223.174]) by core3.amsl.com (Postfix) with ESMTP id 9CAFC3A6985 for ; Fri, 27 Aug 2010 09:49:49 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -75% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100827164950.9CAFC3A6985@core3.amsl.com> Date: Fri, 27 Aug 2010 09:49:49 -0700 (PDT)
Click here!

From webdate.horny@hermanbeun.nl Fri Aug 27 09:49:59 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90413A6994 for ; Fri, 27 Aug 2010 09:49:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...megatron.ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -17.587 X-Spam-Level: X-Spam-Status: No, score=-17.587 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FUZZY_VPILL=0.687, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 U-QQ7wgjkUtV for ; Fri, 27 Aug 2010 09:49:59 -0700 (PDT) Received: from e180223174.adsl.alicedsl.de (e180223174.adsl.alicedsl.de [85.180.223.174]) by core3.amsl.com (Postfix) with ESMTP id 6332F3A6985 for ; Fri, 27 Aug 2010 09:49:57 -0700 (PDT) From: webdav-archive@megatron.ietf.org To: webdav-archive@megatron.ietf.org Subject: webdav-archive@megatron.ietf.org V|AGRA ® Official Seller -75% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100827164958.6332F3A6985@core3.amsl.com> Date: Fri, 27 Aug 2010 09:49:57 -0700 (PDT)
Click here!

From webdate.horny@hermanbeun.nl Fri Aug 27 09:49:52 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38AB3A6843 for ; Fri, 27 Aug 2010 09:49:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...ve@lists.ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -17.587 X-Spam-Level: X-Spam-Status: No, score=-17.587 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FUZZY_VPILL=0.687, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 UJwoRr6EP78g for ; Fri, 27 Aug 2010 09:49:51 -0700 (PDT) Received: from e180223174.adsl.alicedsl.de (e180223174.adsl.alicedsl.de [85.180.223.174]) by core3.amsl.com (Postfix) with ESMTP id 9CB803A6994 for ; Fri, 27 Aug 2010 09:49:49 -0700 (PDT) From: webdav-archive@lists.ietf.org To: webdav-archive@lists.ietf.org Subject: webdav-archive@lists.ietf.org V|AGRA ® Official Seller -75% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100827164950.9CB803A6994@core3.amsl.com> Date: Fri, 27 Aug 2010 09:49:49 -0700 (PDT)
Click here!

From w3c-dist-auth-request@listhub.w3.org Fri Aug 27 12:40:08 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D0C3A6879 for ; Fri, 27 Aug 2010 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.677 X-Spam-Level: X-Spam-Status: No, score=-8.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8] 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 PIbl+3ayJjwA for ; Fri, 27 Aug 2010 12:40:04 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 255953A67B5 for ; Fri, 27 Aug 2010 12:40:03 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Op4lO-0006Z7-Vw for w3c-dist-auth-dist@listhub.w3.org; Fri, 27 Aug 2010 19:38:59 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Op4lN-0006Y3-P4 for w3c-dist-auth@listhub.w3.org; Fri, 27 Aug 2010 19:38:57 +0000 Received: from eu3sys201aob102.obsmtp.com ([207.126.148.85] helo=psmtp.com) by lisa.w3.org with smtp (Exim 4.69) (envelope-from ) id 1Op4lK-0004JN-B5 for w3c-dist-auth@w3.org; Fri, 27 Aug 2010 19:38:57 +0000 Received: from source ([209.85.216.41]) by eu3sys201aob102.postini.com ([207.126.154.11]) with SMTP ID DSNKTHgUMlaLJLGNsbnQPadMb301fNtKHiFd@postini.com; Fri, 27 Aug 2010 19:38:54 UTC Received: by qwf7 with SMTP id 7so4016218qwf.14 for ; Fri, 27 Aug 2010 12:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.1.223 with SMTP id 31mr811808qcg.298.1282937905549; Fri, 27 Aug 2010 12:38:25 -0700 (PDT) Received: by 10.229.98.198 with HTTP; Fri, 27 Aug 2010 12:38:25 -0700 (PDT) In-Reply-To: <4C762B47.2010205@wyona.com> References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> <4C762B47.2010205@wyona.com> Date: Fri, 27 Aug 2010 21:38:25 +0200 Message-ID: From: David Nuescheler To: Michael Wechner Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 X-W3C-Scan-Sig: lisa.w3.org 1Op4lK-0004JN-B5 a8b6d7ceac413899149ea334bb69b3a8 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13310 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Fri, 27 Aug 2010 19:38:58 +0000 Hi Michael, Thanks a lot for your question. On Thu, Aug 26, 2010 at 10:52 AM, Michael Wechner wrote: > can you give a "real-world" example such that I can understand better :-)= ? > And also where the existing "protocols" are lacking? I am more than happy to give you a couple of real-life use cases that may give you a little bit of insight on what i have in mind. Let's assume as a starting point that I have a standard HTML form in a browser that I want a user to enter information. While it doesn't really matter what the application is, to make it really tangible let's say it is a form that I want to let a user update their profile information, such as their first name, last name and birthdate. If we assume that this is fine-grained information that is persisted on the server, one would assume that the user profile could be considered a resource (in the WebDAV sense) and the fine-grained information (first name, last name and birthdate) would lend itself to be properties on that resource (in the webdav sense). Assuming that I wanted to transport this information to a WebDAV server using WebDAV as the communication protocol between my browser and my WebDAV server I would find myself in a situation where I would have to write a very healthy chunk of javascript code working with XHR to come up with the PROPPATCH method and the respective XML for the body of the request to be able to persist my information to WebDAV server. If we extend the use case to a user uploading their profile picture, then the the task to interact with my WebDAV server goes from "difficult" to "impossible" using my standard browser. The goal of this effort is to define an interaction pattern that allows a standard browser to interact with the server in a fine-grained and efficient manner, yet honoring a lot of the semantics and model that have been established around WebDAV. So the above example, in my mind could result in a very simple form that could look like this. In straight up (somewhat simplified) html ... ---
--- ...and would not require the hundreds of lines of code javascript and a very cooperative browser to allow me to update my profile. Further more if we assume that if the client-sided javascript application becomes more complex and would like to interact with the fine-grained information from a JavaScript/XHR standpoint there would be the ability to easily access with a GET the above information as something like: --- { firstname: "David", lastname: "Nuescheler", birthdate: "Oct 31 1974" } --- ... or update the above with something along the lines of a PATCH or a POST with a body similar to... --- -birthdate ^lastModifiedBy : "me" --- ... which would remove the birthdate property and update the lastModifiedBy, directly from a Javascript application. As suggested in the thread before, I agree that the conversations around the model that we are operating on and the respective bindings to specific formats need to be separate conversations, but I think to make it more tangible and real-life as you requested I thought that it may make sense to wrap it into the example. Please let me know if that addresses your question or if it is something else that you were looking for. regards, david On Thu, Aug 26, 2010 at 10:52 AM, Michael Wechner wrote: > David Nuescheler wrote: >> >> Hi All, >> >> Julian and I (and occasionally many others) have been discussing a >> development effort like this for quite while. >> I was involved in mapping the scope of WebDAV (and friends) into a >> Java API called JCR[1][2][3] (on which for example Geoff, Julian and >> Roy participated) and due to my Day[4] job (pun intended) I find >> myself very often in a situation where I need have a standard >> web-browser or client-sided web-application interact with a server to >> exchange fine-grained information. >> > > can you give a "real-world" example such that I can understand better :-)= ? > > And also where the existing "protocols" are lacking? > > Thanks > > Michael >> >> Thanks a lot to everybody for all the comments and input. >> >> I guess my main take from this is that I completely agree that we need >> to separate the "model"-conversation from the >> "format/binding"-conversation. >> >> I would like to mention though that in my mind the goal of making this >> effort relevant, efficient and simple is extremely important as well. >> While I appreciate that the separation of the discussions, I would >> like to volunteer to work on bindings to a JSON + PATCH (multipart >> POST) very early on in the process and keep it in sync with the model >> as a living set of examples for the interaction with the more abstract >> model, to ensure that we keep things practical. >> >> I think there are of a large number of very similar, JSON/POST-based >> "protocols" that are defined in an ad-hoc manner by developers. So >> there should be quite a bit of experience out there, that can help us >> gauge the importance some of requirements fairly quickly. I think if >> we manage to take the combined the experience from WebDAV, AtomPub and >> JCR (and possibly more domain specific efforts like CMIS) in terms of >> the overall scope and the initial relevance of certain features we >> should be in great shape. >> >> regards, >> david >> >> [1] http://jcp.org/en/jsr/detail?id=3D170 >> [2] http://jcp.org/en/jsr/detail?id=3D283 >> [3] http://jcp.org/en/jsr/detail?id=3D333 >> [4] http://www.day.com >> >> > > --=20 David Nuescheler Chief Technology Officer mailto: david.nuescheler@day.com web:=A0 http://www.day.com/ http://dev.day.com twitter: @davidnuescheler From webdav-archive@ietf.org Sat Aug 28 08:00:29 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1945D3A6902 for ; Sat, 28 Aug 2010 08:00:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -10.104 X-Spam-Level: X-Spam-Status: No, score=-10.104 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FUZZY_VPILL=0.687, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HOST_EQ_STATICB=1.372, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 FVv04GGr5uLg for ; Sat, 28 Aug 2010 08:00:28 -0700 (PDT) Received: from static-81-219-85-238.devs.futuro.pl (static-81-219-85-238.devs.futuro.pl [81.219.85.238]) by core3.amsl.com (Postfix) with SMTP id 74D553A68FA for ; Sat, 28 Aug 2010 08:00:27 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -41% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100828150027.74D553A68FA@core3.amsl.com> Date: Sat, 28 Aug 2010 08:00:27 -0700 (PDT)
Click here!

From webdav-archive@ietf.org Sat Aug 28 12:30:27 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DD53A684F for ; Sat, 28 Aug 2010 12:30:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -10.739 X-Spam-Level: X-Spam-Status: No, score=-10.739 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FUZZY_VPILL=0.687, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 AHyCRH+KW34s for ; Sat, 28 Aug 2010 12:30:26 -0700 (PDT) Received: from 189-112-068-004.static.ctbctelecom.com.br (189-112-068-004.static.ctbctelecom.com.br [189.112.68.4]) by core3.amsl.com (Postfix) with SMTP id EF7BD3A686B for ; Sat, 28 Aug 2010 12:30:25 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -98% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100828193025.EF7BD3A686B@core3.amsl.com> Date: Sat, 28 Aug 2010 12:30:25 -0700 (PDT)
Click here!

From sygoop9422@comcast.net Sun Aug 29 01:42:21 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF413A67A5 for ; Sun, 29 Aug 2010 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.858 X-Spam-Level: X-Spam-Status: No, score=-65.858 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, 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 wBTJt0ZTs4N1 for ; Sun, 29 Aug 2010 01:42:20 -0700 (PDT) Received: from comcast.net (c-69-247-227-89.hsd1.fl.comcast.net [69.247.227.89]) by core3.amsl.com (Postfix) with ESMTP id DA0653A67A3 for ; Sun, 29 Aug 2010 01:42:19 -0700 (PDT) From: Meds for strong erection To: webdav-archive@ietf.org Subject: For user webdav-archive, Instant Cash-Back today. Institute Members April variety Date: Sun, 29 Aug 2010 04:42:52 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100829084219.DA0653A67A3@core3.amsl.com> John the s Vukov and language Terex The until
Click here to view as a web page.

Aug 29, 2010

Medshop's link online







Unsubscribe |  Change e-mail address |  Privacy Policy |  About Us

Copyright © 2009 polished Knights Inc. All rights reserved.

Sharp drops in sea level across the Permo

Triassic boundary may be the

proper explanation
for the coal gap.
Whiteway, editor and translator, The Portuguese Expedition to Abyssinia in 1441-1543, 1902. Unalaska Island in the Aleutian Islands.For the endothelium of the cornea, see corneal endothelium.Reference for Welsh language in southern Argentina, Welsh immigration to Patagonia.Beginning in the 1980s, by the early 1990s all countries had restored their democracies. The most studied area is Central High Atlas, where the best preserved and most complete basaltic lava piles are exposed.Lispector was not aware that she was dying at the time she wrote it, though the work is full of premonitions of her upcoming death. In the 17th century, the city was developed as a Russian gate to the Orient. But

may lack some

of the functionality of a registry-controlled scheme and will usually lack accompanying metadata in a controlled scheme.Pouria was the name of an Iranian Darvish who was a wrestling champion and national hero.The street layout is typical of the

old

quarters of many northern European cities, and where the castle perches on top
of a

rocky crag (the remnants of an extinct volcano) the Royal Mile runs down the crest of a ridge from it. Apart from his immense success and reception in Tamil cinema, he has
also
acted in Hindi, Telugu, Malayalam, and Kannada-language films. Engagement on the part of Russia not to impede the commercial and industrial undertakings of Japan in Korea, nor to oppose any measures taken for the purpose of

protecting them so long as

such measures do not infringe the stipulations of Article I. In this trial, which studied almost 20,000 women, raloxifene had fewer side

effects

than tamoxifen, though it did permit more DCIS to form. Along with ice hockey and basketball, football is one of the most popular sports in modern Russia.Note that although almost all Uranium is imported. This Yunnan location article is a stub. The grand gardens
of the baroque
Palace of Caserta.There are 74,285km of oil pipelines in Russia, 13,658km of pipelines for refined products, 158,767km of natural gas pipelines [258] By total length of pipelines Russia is second only to the United States.The most famous natural tourist destination in Russia is lake Baikal, named the Blue Eye of Siberia. By market share measures, domestic markets
are the least open of any OECD country. The Arabic vocabulary in other Iranic, Turkic and Indic languages are generally understood to be have been copied from New Persian.Similarly, cervical cytology testing (using the Pap smear) leads to the identification and excision of precancerous lesions. In Abkhazia and South Ossetia, de facto states inside the de jure territory of Georgia have been formed. This helps observers look for data that can refute a model or help in choosing between several alternate or conflicting models. Together with fellow staff-member Kent Ford, Rubin announced at a 1975 meeting of the American Astronomical Society the discovery that most stars in spiral galaxies orbit at roughly the same speed, which implied that their mass densities were uniform well beyond the locations with most

of

the stars (the galactic bulge). It was founded in November 1939 by the Union of Orthodox Rabbis of the United States and Canada (Agudath Harabbanim) [1]. Extant sources reveal that the early Carolingians had
vassals, as did other leading men in
the kingdom. Georgia withdrew its personnel from the JPKF Headquarters in Tskhinvali. Holes in the ground provided insulation and resulted in better control over firing. United States Census Bureau, Population Division.The hardest holes on the course receive the most handicap strokes, with the easiest holes receiving the least handicap strokes.Linguistic Lineage for Urdu - Ethnologue. The Cyrillic alphabet was introduced for writing the Tajik language under the Tajik Soviet Socialist Republic in the late 1930s, replacing the Latin alphabet that had been used since the Bolshevik revolution and the Perso-Arabic script that had been used earlier. Park Kil-ryong (Kukmin University), modified by Architectural Design Lab, GSNU.
From webdav-archive@ietf.org Sun Aug 29 10:25:59 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0B73A6841 for ; Sun, 29 Aug 2010 10:25:59 -0700 (PDT) X-Quarantine-ID: <0EaD1JGAvTqV> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -5.788 X-Spam-Level: X-Spam-Status: No, score=-5.788 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FUZZY_VPILL=0.687, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 0EaD1JGAvTqV for ; Sun, 29 Aug 2010 10:25:58 -0700 (PDT) Received: from dslb-088-076-184-054.pools.arcor-ip.net (dslb-088-076-184-054.pools.arcor-ip.net [88.76.184.54]) by core3.amsl.com (Postfix) with SMTP id DE9BE3A682D for ; Sun, 29 Aug 2010 10:25:57 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -48% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100829172557.DE9BE3A682D@core3.amsl.com> Date: Sun, 29 Aug 2010 10:25:57 -0700 (PDT)
Click here!

From w3c-dist-auth-request@listhub.w3.org Sun Aug 29 12:07:06 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76F23A686D for ; Sun, 29 Aug 2010 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.027 X-Spam-Level: X-Spam-Status: No, score=-8.027 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8] 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 mjjDliuTCxm4 for ; Sun, 29 Aug 2010 12:07:03 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 3E1803A6859 for ; Sun, 29 Aug 2010 12:07:03 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OpnCG-0000LS-IW for w3c-dist-auth-dist@listhub.w3.org; Sun, 29 Aug 2010 19:05:40 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OpnCF-0000KM-FG for w3c-dist-auth@listhub.w3.org; Sun, 29 Aug 2010 19:05:39 +0000 Received: from eu3sys201aog103.obsmtp.com ([207.126.148.89]) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OpnCD-0003t0-Iu for w3c-dist-auth@w3.org; Sun, 29 Aug 2010 19:05:39 +0000 Received: from source ([209.85.216.53]) by eu3sys201aob103.postini.com ([207.126.154.11]) with SMTP ID DSNKTHqvYl1okYYKHsAJxJtPYD/Z4tvLPKjV@postini.com; Sun, 29 Aug 2010 19:05:37 UTC Received: by qwe5 with SMTP id 5so4443108qwe.26 for ; Sun, 29 Aug 2010 12:05:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.2.85 with SMTP id 21mr2279172qai.165.1283108705432; Sun, 29 Aug 2010 12:05:05 -0700 (PDT) Received: by 10.229.98.198 with HTTP; Sun, 29 Aug 2010 12:05:05 -0700 (PDT) In-Reply-To: <4C77C991.5080700@gmx.de> References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> <4C77C991.5080700@gmx.de> Date: Sun, 29 Aug 2010 21:05:05 +0200 Message-ID: From: David Nuescheler To: Julian Reschke Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OpnCD-0003t0-Iu e707f4d7912c8ad4d57bb48f4f36f707 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Data Model Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13311 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 29 Aug 2010 19:05:40 +0000 Hi Julian, thanks for kickstarting the conversation... Here my initial take on the topics below. > 1. Collections > 1.1 Hierarchy: WebDAV collections are hierarchical. A "direct" member of a > collection has the parent collections URI + one additional path segment. JCR > same. This also means that relative paths do the obvious thing. > CMIS/AtomPub: no constraints on the paths (AFAIU). I think the WebDAV hierarchy approach is great and very important since referencing by (relative) URL is core to basic web things. > 1.2 Multiple containment: allowed in WebDAV through multiple bindings, in > JCR through shared nodes. CMIS/AtomPub: not constrained anyway. While I think that multiple containment is interesting, it is definitely not at the top of my priority list. > 1.3 Identification: WebDAV: the same of a resource within a collection is a > unique identifier. JCR: same (except that for same-name-siblings, the array > index may change when siblings are removed). I think the WebDAV way works perfectly. > 1.4 Ordering: optional features in WebDAV and JCR. I think this is more important for fine-grained content since when we talk about DOM-like structures that are persisted on the server of course the sort order makes a big difference. (As a side comment: mapping things to JSON in the back of my mind creates a bit of tension here, since sort-order of JSON object is undefined, while all implementations in browsers keep the sort-order, technically a JSON parser is not obligated to do that...) > 1.5 Member naming: in WebDAV by path segment (URI syntax), in JCR per > optional namespace name + path segment. I am not sure if we need a special (xml-like) namespace management, it seems like a lot of overhead. > 1.6 Name encoding: in WebDAV per spec ASCII (+ URI percent encoding), in JCR > Unicode. ASCII + URI encoding sounds great > 2. Properties > 2.1 Cardinality: properties can only occur once on a resource, but there are > ways to express lists (WebDAV, JCR) I think there is no need to change that. > 2.2 Typing: optional in WebDAV (see RFC 4316). Set of predefined types in > JCR (int, float, string, date, URI, ...) If we look at the types in a browser javascript runtime it seems that number, strings, boolean and Date seem like obvious candiates. > 2.3 Naming: namespace name + local name (WebDAV, JCR) Great. > 3. Content > 3.1 A single binary stream per HTTP in WebDAV (ignoring content negotiation > for now which is tricky in authoring); modeled as binary property in JCR > (with only conventions on naming) I think in JCR we went all out and in my mind went too far with binaries. I think I would be happy with having a single optional binary stream. More importantly though since this is about fine-grained information the typical case will be having "no" binary at all, but just a tree of properties (and "nodes?"). regards, david From w3c-dist-auth-request@listhub.w3.org Sun Aug 29 12:28:58 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2E43A6875 for ; Sun, 29 Aug 2010 12:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.602 X-Spam-Level: X-Spam-Status: No, score=-7.602 tagged_above=-999 required=5 tests=[AWL=2.997, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 IwOtmPShtlMs for ; Sun, 29 Aug 2010 12:28:57 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 005DC3A6872 for ; Sun, 29 Aug 2010 12:28:56 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1OpnYg-0008QO-CB for w3c-dist-auth-dist@listhub.w3.org; Sun, 29 Aug 2010 19:28:50 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OpnYf-0008PD-Oo for w3c-dist-auth@listhub.w3.org; Sun, 29 Aug 2010 19:28:49 +0000 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1OpnYd-0007ui-Om for w3c-dist-auth@w3.org; Sun, 29 Aug 2010 19:28:49 +0000 Received: (qmail invoked by alias); 29 Aug 2010 19:28:15 -0000 Received: from p508FD357.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.211.87] by mail.gmx.net (mp015) with SMTP; 29 Aug 2010 21:28:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+hyw8nOgKhnwuaMRJYRxuS5pLfr3LEBeY8Si7pCk rYRo+E4whIC3Iq Message-ID: <4C7AB4CE.7070004@gmx.de> Date: Sun, 29 Aug 2010 21:28:14 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Nuescheler CC: w3c-dist-auth@w3.org References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> <4C77C991.5080700@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1OpnYd-0007ui-Om 17198ea3166ebfa233cd5bf418b83fb5 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Data Model Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13312 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Sun, 29 Aug 2010 19:28:50 +0000 On 29.08.2010 21:05, David Nuescheler wrote: > Hi Julian, > > thanks for kickstarting the conversation... :-) I was planning to actually insert my opinion as well, but was waiting for other's views first. Here we go: > Here my initial take on the topics below. > >> 1. Collections >> 1.1 Hierarchy: WebDAV collections are hierarchical. A "direct" member of a >> collection has the parent collections URI + one additional path segment. JCR >> same. This also means that relative paths do the obvious thing. >> CMIS/AtomPub: no constraints on the paths (AFAIU). > I think the WebDAV hierarchy approach is great and very important > since referencing by (relative) URL is core to basic web things. Yes. >> 1.2 Multiple containment: allowed in WebDAV through multiple bindings, in >> JCR through shared nodes. CMIS/AtomPub: not constrained anyway. > While I think that multiple containment is interesting, it is > definitely not at the top of my priority list. Indeed. As we have seen in WebDAV and JCR, it can be added later on without affecting existing code (just be a bit careful when phrasing things, not confusing the identifier with the thing being identified). >> 1.3 Identification: WebDAV: the same of a resource within a collection is a >> unique identifier. JCR: same (except that for same-name-siblings, the array >> index may change when siblings are removed). > I think the WebDAV way works perfectly. +1 >> 1.4 Ordering: optional features in WebDAV and JCR. > I think this is more important for fine-grained content since when we > talk about DOM-like structures that are persisted on the server of > course the sort order makes a big difference. (As a side comment: > mapping things to JSON in the back of my mind creates a bit of tension > here, since sort-order of JSON object is undefined, while all > implementations in browsers keep the sort-order, technically a JSON > parser is not obligated to do that...) > >> 1.5 Member naming: in WebDAV by path segment (URI syntax), in JCR per >> optional namespace name + path segment. > I am not sure if we need a special (xml-like) namespace management, it > seems like a lot of overhead. > >> 1.6 Name encoding: in WebDAV per spec ASCII (+ URI percent encoding), in JCR >> Unicode. > ASCII + URI encoding sounds great Yes, but I think we need to require that percent encoding actually is used to encode UTF-8 sequences. In WebDAV, the interop problems between *nix boxes (octet sequences as filenames) and Windows boxes (Unicode) have been painful. >> 2. Properties >> 2.1 Cardinality: properties can only occur once on a resource, but there are >> ways to express lists (WebDAV, JCR) > I think there is no need to change that. > >> 2.2 Typing: optional in WebDAV (see RFC 4316). Set of predefined types in >> JCR (int, float, string, date, URI, ...) > If we look at the types in a browser javascript runtime it seems that > number, strings, boolean and Date seem like obvious candiates. Yes. I also believe that special casing links would be good. >> 2.3 Naming: namespace name + local name (WebDAV, JCR) > Great. > >> 3. Content >> 3.1 A single binary stream per HTTP in WebDAV (ignoring content negotiation >> for now which is tricky in authoring); modeled as binary property in JCR >> (with only conventions on naming) > I think in JCR we went all out and in my mind went too far with > binaries. I think I would be happy with having a single optional > binary stream. > More importantly though since this is about fine-grained information > the typical case will be having "no" binary at all, but just a tree of > properties (and "nodes?"). Would a zero length content work as well? Best regards, Julian From w3c-dist-auth-request@listhub.w3.org Mon Aug 30 11:09:58 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666173A689F for ; Mon, 30 Aug 2010 11:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8] 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 US3qT5ue6WiU for ; Mon, 30 Aug 2010 11:09:56 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D2DDE3A69C0 for ; Mon, 30 Aug 2010 11:09:55 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Oq8mp-00088q-ON for w3c-dist-auth-dist@listhub.w3.org; Mon, 30 Aug 2010 18:08:51 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq8mo-00087h-EH for w3c-dist-auth@listhub.w3.org; Mon, 30 Aug 2010 18:08:50 +0000 Received: from eu3sys201aog103.obsmtp.com ([207.126.148.89]) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1Oq8mm-0005uS-F8 for w3c-dist-auth@w3.org; Mon, 30 Aug 2010 18:08:50 +0000 Received: from source ([209.85.161.46]) by eu3sys201aob103.postini.com ([207.126.154.11]) with SMTP ID DSNKTHvzk2dpqFz6U5I54aXr1Akz4rLq0ezc@postini.com; Mon, 30 Aug 2010 18:08:48 UTC Received: by fxm13 with SMTP id 13so3455733fxm.19 for ; Mon, 30 Aug 2010 11:08:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.108.9 with SMTP id k9mr471289mum.121.1283191699710; Mon, 30 Aug 2010 11:08:19 -0700 (PDT) Received: by 10.102.228.2 with HTTP; Mon, 30 Aug 2010 11:08:19 -0700 (PDT) In-Reply-To: <4C7AB4CE.7070004@gmx.de> References: <4C63C650.1090301@gmx.de> <4C67D92A.4010505@gmx.de> <4C713D5E.6050400@gmx.de> <4C77C991.5080700@gmx.de> <4C7AB4CE.7070004@gmx.de> Date: Mon, 30 Aug 2010 20:08:19 +0200 Message-ID: From: David Nuescheler To: Julian Reschke Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset=ISO-8859-1 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1Oq8mm-0005uS-F8 8bf7f01176b3aa19c90ee4f91e3ea509 X-Original-To: w3c-dist-auth@w3.org Subject: Re: Data Model Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13313 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Resent-Message-Id: Resent-Date: Mon, 30 Aug 2010 18:08:51 +0000 Hi Julian, thanks for the additional color. Let me chime in on one aspect... >> I think in JCR we went all out and in my mind went too far with >> binaries. I think I would be happy with having a single optional >> binary stream. >> More importantly though since this is about fine-grained information >> the typical case will be having "no" binary at all, but just a tree of >> properties (and "nodes?"). > Would a zero length content work as well? Well, personally, I would rather avoid that route. I thought about this from various different aspects and while it of course works from an implementation and usage standpoint I would argue that it sets the wrong expectation and targets the wrong use cases. In my mind the general case is that the "nodes" (or the lack of a better term) do not have a "binary stream" associated, and in exceptional cases they do. I see the fine-grained nature more similar to rows of a table in relational database. So in my mind it is important to identify the "binary content" as the special case and make sure that the "binary content-less" concept is treated as the general case, and not the other way around. I realize that this is just a matter of setting the perception correctly but that's precisely why would like to be careful ;) regards, david From webdav-archive@ietf.org Mon Aug 30 12:58:12 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D623A6876 for ; Mon, 30 Aug 2010 12:58:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -7.683 X-Spam-Level: X-Spam-Status: No, score=-7.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FUZZY_VPILL=0.687, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, SARE_RECV_SPAM_DOMN02=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 wb7cUDUnGVon for ; Mon, 30 Aug 2010 12:58:07 -0700 (PDT) Received: from 189-69-57-19.dsl.telesp.net.br (189-69-57-19.dsl.telesp.net.br [189.69.57.19]) by core3.amsl.com (Postfix) with SMTP id 208C83A6814 for ; Mon, 30 Aug 2010 12:58:06 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -38% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100830195807.208C83A6814@core3.amsl.com> Date: Mon, 30 Aug 2010 12:58:06 -0700 (PDT)
Click here!

From webdav-archive@ietf.org Mon Aug 30 19:22:25 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8B23A68B3 for ; Mon, 30 Aug 2010 19:22:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -33.968 X-Spam-Level: X-Spam-Status: No, score=-33.968 tagged_above=-999 required=5 tests=[AWL=-14.963, BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FUZZY_VPILL=0.687, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_WS_SURBL=10, 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 CZhpeNa+bh8d for ; Mon, 30 Aug 2010 19:22:25 -0700 (PDT) Received: from 201-75-234-39-am.cpe.vivax.com.br (201-75-234-39-am.cpe.vivax.com.br [201.75.234.39]) by core3.amsl.com (Postfix) with SMTP id 61E233A6452 for ; Mon, 30 Aug 2010 19:22:24 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -58% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100831022224.61E233A6452@core3.amsl.com> Date: Mon, 30 Aug 2010 19:22:24 -0700 (PDT)
Click here!

From rjbani@ug.edu.gh Mon Aug 30 19:51:25 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198143A68B3 for ; Mon, 30 Aug 2010 19:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.864 X-Spam-Level: ** X-Spam-Status: No, score=2.864 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, BAYES_60=1, US_DOLLARS_3=0.63] 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 ebO-e1TDOWTl for ; Mon, 30 Aug 2010 19:51:25 -0700 (PDT) Received: from mailsrv1.ug.edu.gh (mailsrv1.ug.edu.gh [82.206.239.250]) by core3.amsl.com (Postfix) with ESMTP id 3E9313A6452 for ; Mon, 30 Aug 2010 19:51:24 -0700 (PDT) Received: from mailsrv1.ug.edu.gh (localhost [127.0.0.1]) by mailsrv1.ug.edu.gh (Postfix) with ESMTP id 0E6808B1AB1; Tue, 31 Aug 2010 01:04:34 +0000 (GMT) Received: from 82.128.15.226 (SquirrelMail authenticated user rjbani@ug.edu.gh) by mailsrv1.ug.edu.gh with HTTP; Tue, 31 Aug 2010 01:04:34 -0000 (GMT) Message-ID: <2881.82.128.15.226.1283216674.squirrel@mailsrv1.ug.edu.gh> Date: Tue, 31 Aug 2010 01:04:34 -0000 (GMT) Subject: Sequel to your non response From: "Miss Elizabeth Etters" Reply-To: elizabeth.etters20@yahoo.com.hk User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; I am Mrs Elizabeth Etters, a devoted Christian. I have a foundation/Estate uncompleted {valued at USD 2,142,728.00 Dollars} and need you to help me finish it because of my health condition, Everything is available. Please contact me for more details. Private contact email: (elizabeth.etters20@yahoo.com.hk) thank you, God bless you. From webdav-archive@ietf.org Tue Aug 31 05:20:55 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1313A68A9 for ; Tue, 31 Aug 2010 05:20:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -13.323 X-Spam-Level: X-Spam-Status: No, score=-13.323 tagged_above=-999 required=5 tests=[BAYES_80=2, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FUZZY_VPILL=0.687, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 HV0okgzfkP0H for ; Tue, 31 Aug 2010 05:20:54 -0700 (PDT) Received: from 201009170236.user.veloxzone.com.br (201009170236.user.veloxzone.com.br [201.9.170.236]) by core3.amsl.com (Postfix) with SMTP id 1012D3A6861 for ; Tue, 31 Aug 2010 05:20:53 -0700 (PDT) From: webdav-archive@ietf.org To: webdav-archive@ietf.org Subject: webdav-archive@ietf.org V|AGRA ® Official Seller -86% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100831122054.1012D3A6861@core3.amsl.com> Date: Tue, 31 Aug 2010 05:20:53 -0700 (PDT)
Click here!

From rjbani@ug.edu.gh Tue Aug 31 07:14:27 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFBE3A69D7 for ; Tue, 31 Aug 2010 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.031 X-Spam-Level: ** X-Spam-Status: No, score=2.031 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, AWL=0.166, BAYES_50=0.001, US_DOLLARS_3=0.63] 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 Lg6TbDzyzQC9 for ; Tue, 31 Aug 2010 07:14:26 -0700 (PDT) Received: from mailsrv1.ug.edu.gh (mailsrv1.ug.edu.gh [82.206.239.250]) by core3.amsl.com (Postfix) with ESMTP id 911643A6A2C for ; Tue, 31 Aug 2010 07:14:25 -0700 (PDT) Received: from mailsrv1.ug.edu.gh (localhost [127.0.0.1]) by mailsrv1.ug.edu.gh (Postfix) with ESMTP id D94208B1CB8; Tue, 31 Aug 2010 10:57:07 +0000 (GMT) Received: from 82.128.17.9 (SquirrelMail authenticated user rjbani@ug.edu.gh) by mailsrv1.ug.edu.gh with HTTP; Tue, 31 Aug 2010 10:57:08 -0000 (GMT) Message-ID: <1955.82.128.17.9.1283252228.squirrel@mailsrv1.ug.edu.gh> Date: Tue, 31 Aug 2010 10:57:08 -0000 (GMT) Subject: Sequel to your non response From: "Miss Elizabeth Etters" Reply-To: elizabeth.etters20@yahoo.com.hk User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; I am Mrs Elizabeth Etters, a devoted Christian. I have a foundation/Estate uncompleted {valued at USD 2,142,728.00 Dollars} and need you to help me finish it because of my health condition, Everything is available. Please contact me for more details. Private contact email: (elizabeth.etters20@yahoo.com.hk) thank you, God bless you. From info@wins.com Tue Aug 31 22:29:24 2010 Return-Path: X-Original-To: ietfarch-webdav-archive@core3.amsl.com Delivered-To: ietfarch-webdav-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864973A694F for ; Tue, 31 Aug 2010 22:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.301 X-Spam-Level: *** X-Spam-Status: No, score=3.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, GB_SUMOF=5, 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 ycmJENYWJYD0 for ; Tue, 31 Aug 2010 22:29:23 -0700 (PDT) Received: from ece.uprm.edu (ece.uprm.edu [136.145.57.24]) by core3.amsl.com (Postfix) with ESMTP id 1A5DF3A6A88 for ; Tue, 31 Aug 2010 22:29:23 -0700 (PDT) Received: from ece.uprm.edu (localhost [127.0.0.1]) by ece.uprm.edu (Postfix) with ESMTP id 4F743DE495C; Wed, 1 Sep 2010 01:29:53 -0400 (AST) Received: from 41.220.68.1 (SquirrelMail authenticated user victorr) by ece.uprm.edu with HTTP; Wed, 1 Sep 2010 01:29:53 -0400 (AST) Message-ID: <08f19f83a8a85d7bc72bd101f94ca855.squirrel@ece.uprm.edu> Date: Wed, 1 Sep 2010 01:29:53 -0400 (AST) Subject: You Have Won From: =?iso-8859-1?Q?=A92010__Online_National_Lottery?= Reply-To: irsnl@live.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Attn Winner: Your email has just won the sum of 750,000.00 Pounds with the Irish Lottery Commission. Your e-mail address attached to: Ticket Number: 09-11-11 Reference Number: SL/07/4009 For Claims, Contact with your details: ==================================== Name: Sir. Gary Millington LOTTERY CLAIMS/PAY-OUT DEPARTMENT Email: irsnl@live.com ===================================== 1.Full Name: 2.Address: 3.Nationality: 4.Age: 5.Occupation: 6.Home Phone: 7.Work Phone 8.Mobile Phone: 9.Fax: PS: THIS IS A VALID COMPUTER GENERATED LETTER AND DOES NOT REQUIRE ANY SIGNATURE. ======================================== Virginia Carruthers International Senior Coordinator