From owner-atom-protocol Wed Sep 8 08:54:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FsNgT070870 for ; Wed, 8 Sep 2004 08:54:23 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88FsNmo070869 for atom-protocol-skb; Wed, 8 Sep 2004 08:54:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88FsMOj070850 for ; Wed, 8 Sep 2004 08:54:22 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so603266rnk for ; Wed, 08 Sep 2004 08:54:20 -0700 (PDT) Received: by 10.38.59.69 with SMTP id h69mr2813729rna; Wed, 08 Sep 2004 08:54:20 -0700 (PDT) Received: by 10.38.165.69 with HTTP; Wed, 8 Sep 2004 08:54:19 -0700 (PDT) Message-ID: <3f1451f5040908085467fb7821@mail.gmail.com> Date: Wed, 8 Sep 2004 11:54:19 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: atom-protocol@imc.org Subject: Welcome In-Reply-To: <3f1451f5040908085138aad36c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f5040908085138aad36c@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Welcome to [atom-protocol], This design team has been formed as a part of the atompub workgroup. The justification for forming such a group has been covered in PaceProtocolDesignTeam2[1] >From that Pace: "For this design team, we propose a mailing list open to anyone, whose only restriction is that the only initial topic for discussion is the needed actions for the Atom protocol. The protocol design team will propose to the WG ways of closing all open issues in the Atom protocol document. The document editors will revise the protocol document based on what they hear from the WG. " What that means is that the output of this team is a series of Paces, all of which need to be accepted by the whole WG, which means discussion on [atom-syntax]. As we all know, the volume on atom-syntax has drowned out much discussion on the Protocol aspect of atom, as a result the protocol has lagged. The hope is a seperate mailing list will speed up progress. Also note that we are just a design team of the atompub WG and as such are still bound by the charter[2]. That's just my way of saying let's not wander too far afield as we look to move the protocol forward. As a starting point for the discussion I would like to point everyone to the TypePad implementation of the Atom Publishing Protocol[3]. There is a large chunk of functionality there that we currently don't cover such as the UploadURI (which is covered by PaceSimpleResourcePosting) and Categories. We also need to consider which elements are mandatory versus optional, in particular look at the elements that are dropped from the SixApart implementation when posting to a Book list using an ISBN. In addition from our own charter we have the following functionality we must address: * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. [1] http://www.intertwingly.net/wiki/pie/PaceProtocolDesignTeam2 [2] http://www.ietf.org/html.charters/atompub-charter.html [3] http://sixapart.com/developers/atom/typepad/ Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 8 13:38:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Kc38V098003 for ; Wed, 8 Sep 2004 13:38:03 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88Kc35Y098002 for atom-protocol-skb; Wed, 8 Sep 2004 13:38:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88Kc2KM097986 for ; Wed, 8 Sep 2004 13:38:02 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i88KbWud019472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Sep 2004 13:37:32 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C59C7-0001e9-Jh by authid for ; Wed, 08 Sep 2004 13:37:31 -0700 Date: Wed, 8 Sep 2004 13:37:31 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Re: Welcome Message-ID: <20040908203731.GA6232@google.com> References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f5040908085467fb7821@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 08, 2004 at 11:54:19AM -0400, Joe Gregorio wrote: >... > What that means is that the output of this team is a series > of Paces, all of which need to be accepted by the > whole WG, which means discussion on [atom-syntax]. >... > As a starting point for the discussion I would > like to point everyone to the TypePad > implementation of the Atom Publishing > Protocol[3]. There is a large chunk of functionality >... > Categories. We also need to consider > which elements are mandatory versus optional, >... > In addition from our own charter we have the > following functionality we must address: > > * multiple authors for a feed > * multiple subjects or categories in a feed > * user authentication > * adding, editing, and deleting users > * setting and getting user preferences > * creating, getting and setting related resources such as > comments, templates, etc. This is certainly a valid approach to begin discussion -- what is being done today is a good demonstration of "what is needed?" However, I'd like to propose a different path for tackling the problem. Something a bit more methodical: * identify and design the data model - what objects are represented? - what properties do they have? - what are the relationships? * identify the operations needed to operate on the data model * define the protocol around the above items I think the last step will just kind of "fall out" once we have the first two items. Once the operations and data is known, then it becomes relatively trivial to express that within different protocol models (REST, SOAP, etc). This approach also defers the question of protocol representation and allows us to concentrate on the fundamentals of what we're trying to do. Any thoughts on trying this approach? Cheers, -g From owner-atom-protocol Wed Sep 8 14:00:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88L0oPe000220 for ; Wed, 8 Sep 2004 14:00:50 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88L0oDa000219 for atom-protocol-skb; Wed, 8 Sep 2004 14:00:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88L0lce000210; Wed, 8 Sep 2004 14:00:48 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20040908203731.GA6232@google.com> References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> Date: Wed, 8 Sep 2004 14:00:51 -0700 To: Greg Stein , atom-protocol@imc.org From: Paul Hoffman / IMC Subject: Re: Welcome Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:37 PM -0700 9/8/04, Greg Stein wrote: >* identify and design the data model > - what objects are represented? > - what properties do they have? > - what are the relationships? > >* identify the operations needed to operate on the data model > >* define the protocol around the above items > >I think the last step will just kind of "fall out" once we have the first >two items. Once the operations and data is known, then it becomes >relatively trivial to express that within different protocol models (REST, >SOAP, etc). > >This approach also defers the question of protocol representation and >allows us to concentrate on the fundamentals of what we're trying to do. > >Any thoughts on trying this approach? Sounds good to me. People could be keeping side-notes on #3, but if the near-term focus the design is #1 and #2, we're much more likely to hit the actual needs of the users. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-protocol Wed Sep 8 16:26:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88NQpXf012975 for ; Wed, 8 Sep 2004 16:26:51 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88NQpxw012974 for atom-protocol-skb; Wed, 8 Sep 2004 16:26:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i88NQo17012961; Wed, 8 Sep 2004 16:26:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C5BoW-0001pD-R5; Wed, 08 Sep 2004 23:25:20 +0000 Message-ID: <413F9534.90601@franklinmint.fm> Date: Wed, 08 Sep 2004 19:26:44 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Greg Stein , atom-protocol@imc.org Subject: Protocol Data Model References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At 1:37 PM -0700 9/8/04, Greg Stein wrote: > >> * identify and design the data model >> - what objects are represented? >> - what properties do they have? >> - what are the relationships? >> >> * identify the operations needed to operate on the data model >> The wiki seems like a pretty good place to sketch in these two points. Tracking mailing list threads will get old fast. I've started http://www.intertwingly.net/wiki/pie/ProtocolDataModel with objects and properties gleaned from the WG charter. Add and restructure as you like, but let's keep the debate on-list. Robert Sayre From owner-atom-protocol Wed Sep 8 21:43:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i894hTVq037230 for ; Wed, 8 Sep 2004 21:43:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i894hTsq037229 for atom-protocol-skb; Wed, 8 Sep 2004 21:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i894hSLf037223 for ; Wed, 8 Sep 2004 21:43:28 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 86193 invoked by uid 17064); 9 Sep 2004 04:43:35 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.139.127]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 04:43:35 -0000 In-Reply-To: <413F9534.90601@franklinmint.fm> References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> <413F9534.90601@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Danny Ayers From: Henry Story Subject: Re: Protocol Data Model Date: Thu, 9 Sep 2004 06:43:28 +0200 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i894hSLf037224 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The data model work has already been done. Check out Danny Ayer's Atom-OWL model [1] or my more experimental model [2] which I have even illustrated with a UML diagram. The OWL file [3] contain that information in a formal w3c supported, machine readable way. To interact with those models directly tools such as Protégé are available. On 9 Sep 2004, at 01:26, Robert Sayre wrote: > >> At 1:37 PM -0700 9/8/04, Greg Stein wrote: >>> * identify and design the data model >>> - what objects are represented? >>> - what properties do they have? >>> - what are the relationships? The OWL model specifies all the above. >>> >>> * identify the operations needed to operate on the data model >>> > > The wiki seems like a pretty good place to sketch in these two points. > Tracking mailing list threads will get old fast. > > I've started > > http://www.intertwingly.net/wiki/pie/ProtocolDataModel > > with objects and properties gleaned from the WG charter. Add and > restructure as you like, but let's keep the debate on-list. > > Robert Sayre Henry Story http://bblfish.net/ [1] http://semtext.org/atom/atom.html [2] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html [3] http://bblfish.net/work/atom-owl/2004-08-12/Atom.n3 or http://bblfish.net/work/atom-owl/2004-08-12/Atom.owl [4] http://protege.stanford.edu/ (download full installation) From owner-atom-protocol Thu Sep 9 03:26:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89AQvUV082233 for ; Thu, 9 Sep 2004 03:26:57 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89AQvsH082232 for atom-protocol-skb; Thu, 9 Sep 2004 03:26:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89AQtXg082212 for ; Thu, 9 Sep 2004 03:26:56 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i89AQt111721 for ; Thu, 9 Sep 2004 13:26:55 +0300 (EET DST) X-Scanned: Thu, 9 Sep 2004 13:26:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i89AQYvO029831 for ; Thu, 9 Sep 2004 13:26:34 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00x9bWzv; Thu, 09 Sep 2004 13:26:32 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i89AQWS08970 for ; Thu, 9 Sep 2004 13:26:32 +0300 (EET DST) Received: from [172.21.60.114] ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Sep 2004 13:26:08 +0300 Message-ID: <41402FBF.2080306@nokia.com> Date: Thu, 09 Sep 2004 13:26:07 +0300 From: Janne Jalkanen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619 X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: atom-protocol@imc.org Subject: Re: Welcome References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2004 10:26:08.0251 (UTC) FILETIME=[6B772CB0:01C49657] Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 'ello all! > Sounds good to me. People could be keeping side-notes on #3, but if > the near-term focus the design is #1 and #2, we're much more likely to > hit the actual needs of the users. Um. One of the needs of the users is quick execution. :) http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=109&STORY=/www/story/09-08-2004/0002246056&EDATE= "TypePad's new mobile features and the web features of Nokia Lifeblog will be demonstrated at DEMOmobile, a gathering of mobile industry key players in La Jolla, CA. The blogging capability of Nokia Lifeblog is based on the open ATOM standard, and will be available early 2005." So there's interest in Atom. And from our side, the Atom protocol as it is currently defined, is rather close to actual needs already. The binary format, metadata, and the feed state management have been our headaches, but PaceSimpleResourcePosting, PaceExtendedResourcePosting and the current discussion in atom-syntax seem good in that regard. I think we have a good base in the current protocol to start with. It seems to work in real life :) /Janne From owner-atom-protocol Sat Sep 11 06:34:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BDYZDp003620 for ; Sat, 11 Sep 2004 06:34:36 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BDYZWk003619 for atom-protocol-skb; Sat, 11 Sep 2004 06:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BDYZ53003610 for ; Sat, 11 Sep 2004 06:34:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C681Q-0005b1-5r for atom-protocol@imc.org; Sat, 11 Sep 2004 13:34:32 +0000 Message-ID: <4142FEF1.3000006@franklinmint.fm> Date: Sat, 11 Sep 2004 09:34:41 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-protocol@imc.org Subject: ProtocolDataModel issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Note that this data model is distinct from that of an Atom feed. http://www.intertwingly.net/wiki/pie/ProtocolDataModel Access control-- Blogs need access control settings. Entries do as well. Think of a draft post as "-rw-r-----". Users-- Greg Stein suggested using Principals from the WebDAV ACL spec as our conceptual model. http://webdav.org/specs/rfc3744.html#principals Templates-- Greg Stein: "how do we describe which syntax the template is using?" Could we use MIME? Vendors could register their template languages under vnd. or prs. Robert Sayre From owner-atom-protocol Sat Sep 11 09:32:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BGWjk8013412 for ; Sat, 11 Sep 2004 09:32:45 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BGWjea013411 for atom-protocol-skb; Sat, 11 Sep 2004 09:32:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BGWiLt013403 for ; Sat, 11 Sep 2004 09:32:44 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so69407rnb for ; Sat, 11 Sep 2004 09:32:42 -0700 (PDT) Received: by 10.38.8.74 with SMTP id 74mr431650rnh; Sat, 11 Sep 2004 09:32:42 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 11 Sep 2004 09:32:42 -0700 (PDT) Message-ID: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> Date: Sat, 11 Sep 2004 18:32:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: <4142FEF1.3000006@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 11 Sep 2004 09:34:41 -0400, Robert Sayre wrote: > > Note that this data model is distinct from that of an Atom feed. Distinct, ok, but why different? Shouldn't the feed model act as a starting point? So we'd have constructs like Feed, Entry, Person and so on defined as in the format, with additions needed in the context of the protocol layered on top. > http://www.intertwingly.net/wiki/pie/ProtocolDataModel I'm also a little puzzled by, e.g. Post Page: "A formatted display of a single entry.". - the model part is the Entry, surely the presentation should be dealt with separately? > Access control-- > Blogs need access control settings. > Entries do as well. Think of a draft post as "-rw-r-----". > > Users-- > Greg Stein suggested using Principals from the WebDAV ACL spec as our > conceptual model. http://webdav.org/specs/rfc3744.html#principals Ok, on the to-read list, this certainly sounds worth considering... > Templates-- > Greg Stein: "how do we describe which syntax the template is using?" > Could we use MIME? Vendors could register their template languages under > vnd. or prs. Lost me. Could you please explain how the syntax of templates relates to the data model. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Sat Sep 11 10:41:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BHffu4016833 for ; Sat, 11 Sep 2004 10:41:41 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8BHffNq016832 for atom-protocol-skb; Sat, 11 Sep 2004 10:41:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8BHfeNT016826 for ; Sat, 11 Sep 2004 10:41:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C6Bsa-0005SB-Tw; Sat, 11 Sep 2004 17:41:41 +0000 Message-ID: <414338E0.2020106@franklinmint.fm> Date: Sat, 11 Sep 2004 13:41:52 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> In-Reply-To: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Danny Ayers wrote: > On Sat, 11 Sep 2004 09:34:41 -0400, Robert Sayre wrote: > >>Note that this data model is distinct from that of an Atom feed. > > > Distinct, ok, but why different? Shouldn't the feed model act as a > starting point? > Well, sure. I was responding to comments that this work was "already done." Think of this exercise as a model for the resources the server must make available. There's more than just Atom format stuff there. For example, there's the a lot of functionality that would typically go in an admin screen in MT, Wordpress, etc. Adding/Removing users, adding categories, stuff like that. Make sense? > >>http://www.intertwingly.net/wiki/pie/ProtocolDataModel > > > I'm also a little puzzled by, e.g. Post Page: "A formatted display of > a single entry.". - the model part is the Entry, surely the > presentation should be dealt with separately? > The HTML representations are objects the model could take into account. > >>Templates-- >>Greg Stein: "how do we describe which syntax the template is using?" >>Could we use MIME? Vendors could register their template languages under >>vnd. or prs. > > > Lost me. Could you please explain how the syntax of templates relates > to the data model. > The protocol must provide capabilities for modification of templates (see charter). One of the properties of a template is its syntax/language. One way of identifying the "language" of a template is to give it a MIME type. Robert Sayre From owner-atom-protocol Mon Sep 13 03:07:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DA7gBY089088 for ; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DA7ge1089087 for atom-protocol-skb; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DA7gli089077 for ; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so377647rnb for ; Mon, 13 Sep 2004 03:07:43 -0700 (PDT) Received: by 10.38.8.61 with SMTP id 61mr1410600rnh; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Mon, 13 Sep 2004 03:07:42 -0700 (PDT) Message-ID: <1f2ed5cd040913030721e366e5@mail.gmail.com> Date: Mon, 13 Sep 2004 12:07:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-protocol@imc.org Subject: Entry deletion and distributed systems Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If someone posts an entry and then later retracts it a local system can handle this ok, but distributing the retraction may not be quite so straightforward. Maybe it is feasible to distribute the entry identifier tagged as 'withdrawn' or even 'expired', but I suspect it may not be sensible to make anything of that at a global level, as it could never be 100% reliable and the inclusion of such a system in the specs may lead to unrealistic expectations. In other words, I'd suggest that rather than having the logic: Post => EntryExists Post & PostRetraction => !EntryExists We use: Post => EntryExists Post & PostRetraction => EntryExists & PostRetraction (and that's all!) - it's up to the end-user application to deal with that as it sees fit. So generally (web-wide) entries will only expire by get old and slipping into obscurity, not through any explicit (un)assertion. I believe this is consistent with the monotonicity and open world assumptions the logicians favour for reasoning on the web. Whatever, it's maybe something worth bearing in mind during discussions of caching and passing big data aggregations around. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Mon Sep 13 12:30:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJU2uE057251 for ; Mon, 13 Sep 2004 12:30:02 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJU2qA057250 for atom-protocol-skb; Mon, 13 Sep 2004 12:30:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJU2La057175 for ; Mon, 13 Sep 2004 12:30:02 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i8DJTedM022934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2004 12:29:45 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C6wWB-0002ci-Nw by authid ; Mon, 13 Sep 2004 12:29:39 -0700 Date: Mon, 13 Sep 2004 12:29:39 -0700 From: Greg Stein To: Robert Sayre Cc: Danny Ayers , atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040913192939.GA9997@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414338E0.2020106@franklinmint.fm> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 11, 2004 at 01:41:52PM -0400, Robert Sayre wrote: > Danny Ayers wrote: > >On Sat, 11 Sep 2004 09:34:41 -0400, Robert Sayre > >wrote: > > > >>Note that this data model is distinct from that of an Atom feed. > > > >Distinct, ok, but why different? Shouldn't the feed model act as a > >starting point? > > Well, sure. I was responding to comments that this work was "already > done." Think of this exercise as a model for the resources the server > must make available. There's more than just Atom format stuff there. For > example, there's the a lot of functionality that would typically go in > an admin screen in MT, Wordpress, etc. Adding/Removing users, adding > categories, stuff like that. Make sense? I think it makes sense. And I also think that we need to be careful to define some limits around what the spec will cover and then be able to say "go use some other standard to deal with the rest of the stuff." Personally, I'd like to see the resource types and properties defined for all the things we need to manipulate, then just defer to WebDAV to do that. And use its extensible property model for all the vendor-specific stuff that people want. > >>http://www.intertwingly.net/wiki/pie/ProtocolDataModel > > > >I'm also a little puzzled by, e.g. Post Page: "A formatted display of > >a single entry.". - the model part is the Entry, surely the > >presentation should be dealt with separately? > > The HTML representations are objects the model could take into account. A URL points to a resource. Every resource should have a listing in our data model. In this case, a post page is a typical item in a blog setup, so I think it is important to have in the model. There are also relationships that are defined between that page and others in a blog. The important part is that the system is not necessarily a pure MVC, and it may not be described that way. The model is implied by the rules of HTTP, and its notions of resources and methods on those resources. > >>Templates-- > >>Greg Stein: "how do we describe which syntax the template is using?" > >>Could we use MIME? Vendors could register their template languages under > >>vnd. or prs. Ah. That sounds good. > >Lost me. Could you please explain how the syntax of templates relates > >to the data model. > > The protocol must provide capabilities for modification of templates > (see charter). One of the properties of a template is its > syntax/language. One way of identifying the "language" of a template is > to give it a MIME type. There are a number of reasons why you may want to know the syntax of the template. Imagine you have Mother-Of-All-Blog-Tools and it knows how to author 10 different, common template syntaxes. How does it know which of those is in use? Thus, the need for a property. Cheers, -g From owner-atom-protocol Mon Sep 13 12:32:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJW1JU057503 for ; Mon, 13 Sep 2004 12:32:01 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJW1ZU057502 for atom-protocol-skb; Mon, 13 Sep 2004 12:32:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJW1JK057484 for ; Mon, 13 Sep 2004 12:32:01 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i8DJW0j3023633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Sep 2004 12:32:00 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C6wYR-0002d0-Er by authid for ; Mon, 13 Sep 2004 12:31:59 -0700 Date: Mon, 13 Sep 2004 12:31:59 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Q: required extensions? Message-ID: <20040913193159.GB9997@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm confused about the "required extensions" under the Entries data type. That seems like an oxymoron to me. If it is required, then it is part of the definition, isn't it? And not an "extension". Robert: I think you put that in there. Can you elaborate a bit? Cheers, -g From owner-atom-protocol Mon Sep 13 12:52:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJqU16059432 for ; Mon, 13 Sep 2004 12:52:30 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DJqUNk059431 for atom-protocol-skb; Mon, 13 Sep 2004 12:52:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DJqT7K059416 for ; Mon, 13 Sep 2004 12:52:29 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C6wsF-00030Z-Kz; Mon, 13 Sep 2004 19:52:27 +0000 Message-ID: <4145FA6F.8010606@franklinmint.fm> Date: Mon, 13 Sep 2004 15:52:15 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: atom-protocol@imc.org Subject: Re: Q: required extensions? References: <20040913193159.GB9997@google.com> In-Reply-To: <20040913193159.GB9997@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > I'm confused about the "required extensions" under the Entries data type. > That seems like an oxymoron to me. If it is required, then it is part of > the definition, isn't it? And not an "extension". > > Robert: I think you put that in there. Can you elaborate a bit? I was thinking of an Entry resource that was part of something like a Typepad Typelist. For example, a server might require a Music Typelist[0] Entry to contain a http://sixapart.com/atom/song#:album element. Robert Sayre [0] http://sixapart.com/developers/atom/typepad/#Adding_a_Song_to_a_Music_TypeList From owner-atom-protocol Mon Sep 13 13:14:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DKEElD061486 for ; Mon, 13 Sep 2004 13:14:14 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DKEEQp061485 for atom-protocol-skb; Mon, 13 Sep 2004 13:14:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DKEEPn061476 for ; Mon, 13 Sep 2004 13:14:14 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id F25A147BF7; Mon, 13 Sep 2004 13:13:19 -0700 (PDT) In-Reply-To: <414338E0.2020106@franklinmint.fm> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: Robert Sayre From: Ezra Cooper Subject: Re: ProtocolDataModel issues Date: Mon, 13 Sep 2004 13:14:44 -0700 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are some kinds of resources that I'd be interested in modeling in Atom: * Non-entry resources (images, etc.) * Templates - template body - name - target filename * Authors (Principals) * Categories * Weblog-level configuration Can we agree on at least a few weblog-level configuration fields that would be useful to be treated by the protocol? Such as title, description, HTML URL, maybe timezone... At the very least, having a URL for the blog entity provides a convenient place to do the "introspection" that you wouldn't want to expose on the public web pages; it could include service.* links to all the other editable resources. In the case of templates, I assume we all need a body and a name--but there's a lot of variation in determining what templates get used for what target pages. +1 to using MIME types to label the template language. The WebDAV ACL model looks interesting. At first blush it seems cumbersome, but having a ready-to-go spec for that functionality is attractive. In regard to ProtocolDataModel, what is intended by the items "Index Page" and "Post Page"? Are the outward-facing blog pages meant to be treated by the protocol? What operations would they permit? On Sep 13, 2004, at 12:29 PM, Greg Stein wrote: >>> I'm also a little puzzled by, e.g. Post Page: "A formatted display >>> of >>> a single entry.". - the model part is the Entry, surely the >>> presentation should be dealt with separately? > > A URL points to a resource. Every resource should have a listing in our > data model. In this case, a post page is a typical item in a blog > setup, > so I think it is important to have in the model. There are also > relationships that are defined between that page and others in a blog. But what is a "Post Page"? How is it different from an Entry and what is it useful for within the model? Ezra From owner-atom-protocol Tue Sep 14 14:45:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELjPFu019030 for ; Tue, 14 Sep 2004 14:45:25 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ELjP7C019029 for atom-protocol-skb; Tue, 14 Sep 2004 14:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ELjPMR019022 for ; Tue, 14 Sep 2004 14:45:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7L77-0007X6-Pf; Tue, 14 Sep 2004 21:45:25 +0000 Message-ID: <4147666B.6010501@franklinmint.fm> Date: Tue, 14 Sep 2004 17:45:15 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> In-Reply-To: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > Here are some kinds of resources that I'd be interested in modeling in > Atom: > > * Non-entry resources (images, etc.) PaceSimpleResoucePosting takes care of this, right? I guess the only remaining question is how a client locates them, or what resource has these non-entry resources as a many: property. > * Templates > - template body > - name > - target filename Could this be rephrased as - content - MIME type - title - URI > * Authors (Principals) > * Categories What properties does a category need? - name - URI http://www.novell.com/documentation/director4/docs/help/books/cmgWebDAVClient.html#1003177 Has an example of applying "category references" to resources. I'm not saying we have to use WebDAV to do this. There's a clearly a tension between Atom and WebDAV metadata containment models. [0,1,2] > * Weblog-level configuration > > Can we agree on at least a few weblog-level configuration fields that > would be useful to be treated by the protocol? Such as title, > description, HTML URL, maybe timezone... What constitutes Weblog-level? Is there a vague agreement here? Robert Sayre [0] http://www.goland.org/Tech/spe-whitehead.pdf [see "Containment Model"] [1] http://www.franklinmint.fm/blog/archives/000180.html [2] http://www.franklinmint.fm/blog/archives/000174.html From owner-atom-protocol Tue Sep 14 16:43:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENhtuq028516 for ; Tue, 14 Sep 2004 16:43:55 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8ENht7j028515 for atom-protocol-skb; Tue, 14 Sep 2004 16:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ENhqKe028505 for ; Tue, 14 Sep 2004 16:43:54 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [69.17.92.244] (dsl017-092-244.sfo4.dsl.speakeasy.net [69.17.92.244]) by rongo.sixapart.com (Postfix) with ESMTP id BE88B47BF7 for ; Tue, 14 Sep 2004 16:42:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4147666B.6010501@franklinmint.fm> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ezra Cooper Subject: Re: ProtocolDataModel issues Date: Tue, 14 Sep 2004 16:43:22 -0700 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > Ezra Cooper wrote: >> Here are some kinds of resources that I'd be interested in modeling >> in Atom: >> * Non-entry resources (images, etc.) > > PaceSimpleResoucePosting takes care of this, right? I guess the only > remaining question is how a client locates them, or what resource has > these non-entry resources as a many: property. Yes, I think so. I don't see any need to model these as anything other than a generic web resource. >> * Templates >> - template body >> - name >> - target filename > > Could this be rephrased as > - content > - MIME type > - title > - URI Is "URI" the for the XML Atom resource, or for the public HTML file? I was groping for a way to determine the URLs of the public HTML files. We could certainly have a static URL field to be used for templates that only generate one HTML file. However, a common scenario is that where one template will generate many HTML files, at URLs determined by a given pattern. If we wanted to get fancy, we could make the "URI" field MIME-typed, like the content field, so that you could use a template language to specify the scheme of URLs generated by that template. Clients could treat it as a vanilla text box, or they could provide UI help for certain URL-template languages. >> * Authors (Principals) >> * Categories > > What properties does a category need? > - name > - URI Do we want to model categories as hierarchical or flat, or as DAGs? If flat, then hierarchical tools might have to write out long path names for their categories. Do we stop at having a single parent for each category, or can we allow several parents (giving rise to DAGs)? Looks like there are at least two or three possible models for categories. I favor a hierarchical model, possibly with a fallback for tools that don't want to deal with hierarchies. For the fallback, it might be enough just to make sure that each category has a unique human-readable name so that users can select a category without seeing the hierarchy. >> * Weblog-level configuration >> Can we agree on at least a few weblog-level configuration fields that >> would be useful to be treated by the protocol? Such as title, >> description, HTML URL, maybe timezone... > > What constitutes Weblog-level? Is there a vague agreement here? What constitutes a "weblog"? The question of a generation. Here I'm thinking of something that corresponds to a "feed" but the "feed" is the reader's-side view and this entity would be the publisher's-side view. A feed is something fed to you; this is more like cooking. Maybe this is the same as the PostURI; maybe when you GET the PostURI, you get this feed-level resource. To rephrase that, suppose the PostURI is really a "weblog resource" or an "editable feed resource." When you POST to that resource, you're posting a new entry into the feed. When you GET that resource, you get the feed-level metadata (or even the full feed). This resource would also be the place where feed configuration extensions could be made. This would also be a place to offer links for discoverability of the other "lists": like the list of available categories. Currently, in TypePad, to get a list of available categories, you GET a URL ending in "/t/atom/weblog/blog_id=/svc=categories". Rather than set a standard form for this URL, I'm proposing it be chosen by the server and listed in the uber-discoverability resource which can be GOT at the PostURI. I like the idea of hiding most of the discoverability links at this feed-level resource, as opposed to dragging them down the front street on the HTML page. As has been discussed before, in a system with multiple blogs per author, author X might not want to reveal that she authors blogs B and C in addition to A; but she wants her posting client to recognize this so that she can move amongst them with ease. A GET on the PostURI would be authenticated. Alternatively, instead of offer links to other lists, we could bundle all that data into the result you GET at the PostURI. Also at the feed level in the protocol: how about a link to the server's help pages? In various places in a posting client, you might need to refer to docs for, say, the server's template language. The client could display an icon that links to the help link provided by the server. This would be an optional element at the weblog/feed level. It feels wrong to call this *thing* a "feed" on the protocol side, since it is editable. I don't want to be weblog-specific, either. What can we call an editable feed? Can we distinguish it from a "feed" per se, which is the thing documented over at "Atom Format" [1]? Ezra [1] http://ietfreport.isoc.org/idref/draft-ietf-atompub-format/ From owner-atom-protocol Tue Sep 14 19:35:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2Z6A5039272 for ; Tue, 14 Sep 2004 19:35:06 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F2Z5sO039270 for atom-protocol-skb; Tue, 14 Sep 2004 19:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2Z30b039252 for ; Tue, 14 Sep 2004 19:35:04 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7PdS-0003iI-61; Wed, 15 Sep 2004 02:35:06 +0000 Message-ID: <4147AA60.6030007@franklinmint.fm> Date: Tue, 14 Sep 2004 22:35:12 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Template IO (was: ProtocolDataModel issues) References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > >> Ezra Cooper wrote: >> >>> * Templates >>> - template body >>> - name >>> - target filename >> >> >> Could this be rephrased as >> - content >> - MIME type >> - title >> - URI > > > Is "URI" the for the XML Atom resource, or for the public HTML file? > > I was groping for a way to determine the URLs of the public HTML files. > We could certainly have a static URL field to be used for templates that > only generate one HTML file. However, a common scenario is that where > one template will generate many HTML files, at URLs determined by a > given pattern. If we wanted to get fancy, we could make the "URI" field > MIME-typed, like the content field, so that you could use a template > language to specify the scheme of URLs generated by that template. > Clients could treat it as a vanilla text box, or they could provide UI > help for certain URL-template languages. Oh... this is much more involved than what I was thinking of. I had a SimpleResource in mind, with a title property and maybe some notion of templateness. The URI would be where you PUT the template to update it. Now I understand that "target filename" was supposed to be roughly analogous to the "output file" in Movable Type. For those not familiar with MT template configuration, here's a screenshot: http://franklinmint.fm/archives/images/mt_interface.jpg The output filename seems to be way a to say that resource/collection A is a view of resource/collection B (the view is probably limited in quantity, time frame, etc). so B --> template --> A or B --> [input set] --> template --> [output set] --> A So the question is whether the input and output selection can be specified in an interoperable manner. I'm pessimistic, but if the WG can come to consensus, great. In other words, I think "output file" is really part of MT's template format. In WebDAV terms, an extension property. My feeling is that by leaving this up to MIME, there's space for future standardization work on templating. Robert Sayre From owner-atom-protocol Wed Sep 15 08:15:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FFFYKp012086 for ; Wed, 15 Sep 2004 08:15:34 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FFFYcj012085 for atom-protocol-skb; Wed, 15 Sep 2004 08:15:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FFFXp3012077 for ; Wed, 15 Sep 2004 08:15:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7bVJ-0003Pa-VN; Wed, 15 Sep 2004 15:15:30 +0000 Message-ID: <41485C91.3010103@franklinmint.fm> Date: Wed, 15 Sep 2004 11:15:29 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Categories (was: ProtocolDataModel issues) References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > >> What properties does a category need? >> - name >> - URI > > > Do we want to model categories as hierarchical or flat, or as DAGs? If > flat, then hierarchical tools might have to write out long path names > for their categories. Do we stop at having a single parent for each > category, or can we allow several parents (giving rise to DAGs)? Looks > like there are at least two or three possible models for categories. > > I favor a hierarchical model, possibly with a fallback for tools that > don't want to deal with hierarchies. For the fallback, it might be > enough just to make sure that each category has a unique human-readable > name so that users can select a category without seeing the hierarchy. > I meant DAG (I missed a many:parent property). We have a similar problem to users/principals[0] in WebDAV ACL, which defines a DAV:group-membership property[1]. We could revise this to: Category - URI - many: memberOfURIs - many: memberURIs (can be entrys or categories) - name Are you in favor of restricting categories to a hierarchical model, or just concerned about a requirement? I was thinking servers could restrict the model as they wish. Robert Sayre [0] http://webdav.org/specs/rfc3744.html#principal.properties [1] http://webdav.org/specs/rfc3744.html#rfc.section.4.4 From owner-atom-protocol Wed Sep 15 09:22:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGMOoQ018009 for ; Wed, 15 Sep 2004 09:22:24 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGMOrB018008 for atom-protocol-skb; Wed, 15 Sep 2004 09:22:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGMNUC018002 for ; Wed, 15 Sep 2004 09:22:24 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FGMP110395 for ; Wed, 15 Sep 2004 19:22:25 +0300 (EET DST) X-Scanned: Wed, 15 Sep 2004 19:21:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8FGLqJ2017707 for ; Wed, 15 Sep 2004 19:21:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00splv9q; Wed, 15 Sep 2004 19:21:49 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8FFjsY08026 for ; Wed, 15 Sep 2004 18:45:54 +0300 (EET DST) Received: from [172.21.60.114] ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Sep 2004 18:45:47 +0300 Message-ID: <414863AA.70107@nokia.com> Date: Wed, 15 Sep 2004 18:45:46 +0300 From: Janne Jalkanen User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2004 15:45:47.0465 (UTC) FILETIME=[11A57B90:01C49B3B] Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> PaceSimpleResoucePosting takes care of this, right? I guess the only >> remaining question is how a client locates them, or what resource has >> these non-entry resources as a many: property. > > Yes, I think so. I don't see any need to model these as anything other > than a generic web resource. Generic web resources *with metadata* :-) Actually, one thing I would like to work on is the PaceExtendedResourcePosting. >>> * Templates >> Hmm... Are templates possibly too platform-specific? > > I like the idea of hiding most of the discoverability links at this > feed-level resource, as opposed to dragging them down the front street > on the HTML page. As has been discussed before, in a system with > multiple blogs per author, author X might not want to reveal that she > authors blogs B and C in addition to A; but she wants her posting > client to recognize this so that she can move amongst them with ease. > A GET on the PostURI would be authenticated. +1 on the basic idea, +0.1 on the GET on PostURI... Sort of smells like overloading a function with a functionality that is not quite there. It smells of a hack :). Still, it does make sense on some metaphysical level. After all, it is a resource to POST things to... > Also at the feed level in the protocol: how about a link to the > server's help pages? In order to provide generic Wiki editing capabilities, it would be useful to have a guide to the WikiMarkup, yes :) So a resounding +1 to this one. /Janne From owner-atom-protocol Wed Sep 15 09:34:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGY8E4018993 for ; Wed, 15 Sep 2004 09:34:08 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGY85D018992 for atom-protocol-skb; Wed, 15 Sep 2004 09:34:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGY69p018983 for ; Wed, 15 Sep 2004 09:34:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so1053977rnb for ; Wed, 15 Sep 2004 09:34:05 -0700 (PDT) Received: by 10.38.8.74 with SMTP id 74mr3251925rnh; Wed, 15 Sep 2004 09:34:05 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Wed, 15 Sep 2004 09:34:05 -0700 (PDT) Message-ID: <1f2ed5cd040915093461edc110@mail.gmail.com> Date: Wed, 15 Sep 2004 18:34:05 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Categories (was: ProtocolDataModel issues) Cc: Ezra Cooper , atom-protocol@imc.org In-Reply-To: <41485C91.3010103@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <41485C91.3010103@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: First of all I'm not at all sure categories have a place in the protocol at all, or for that matter anywhere in core Atom. Categorization on the web is a hard problem with different solutions being more appropriate in some circumstances than others. Secondly, if categories are to be considered in scope, then please can we not mandate a hierarchical model. Trees are too restrictive to use directly for many kinds of categorization, and often you have to make up ugly hacks to work around them. I'm a big fan of DAGs, but I think even such a restriction is a step too far. I go along with the idea of the servers using whatever model they wish. Cheers, Danny. On Wed, 15 Sep 2004 11:15:29 -0400, Robert Sayre wrote: > > Ezra Cooper wrote: > > > > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote: > > > >> What properties does a category need? > >> - name > >> - URI > > > > > > Do we want to model categories as hierarchical or flat, or as DAGs? If > > flat, then hierarchical tools might have to write out long path names > > for their categories. Do we stop at having a single parent for each > > category, or can we allow several parents (giving rise to DAGs)? Looks > > like there are at least two or three possible models for categories. > > > > I favor a hierarchical model, possibly with a fallback for tools that > > don't want to deal with hierarchies. For the fallback, it might be > > enough just to make sure that each category has a unique human-readable > > name so that users can select a category without seeing the hierarchy. > > > > I meant DAG (I missed a many:parent property). We have a similar problem > to users/principals[0] in WebDAV ACL, which defines a > DAV:group-membership property[1]. We could revise this to: > > Category > - URI > - many: memberOfURIs > - many: memberURIs (can be entrys or categories) > - name > > Are you in favor of restricting categories to a hierarchical model, or > just concerned about a requirement? I was thinking servers could > restrict the model as they wish. > > Robert Sayre > > [0] http://webdav.org/specs/rfc3744.html#principal.properties > [1] http://webdav.org/specs/rfc3744.html#rfc.section.4.4 > > -- http://dannyayers.com From owner-atom-protocol Wed Sep 15 09:49:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGnXGV020519 for ; Wed, 15 Sep 2004 09:49:33 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FGnXMv020518 for atom-protocol-skb; Wed, 15 Sep 2004 09:49:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FGnXKp020508 for ; Wed, 15 Sep 2004 09:49:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7cyH-0002Wh-28; Wed, 15 Sep 2004 16:49:29 +0000 Message-ID: <4148729A.8070406@franklinmint.fm> Date: Wed, 15 Sep 2004 12:49:30 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Ezra Cooper , atom-protocol@imc.org Subject: Re: Categories References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <41485C91.3010103@franklinmint.fm> <1f2ed5cd040915093461edc110@mail.gmail.com> In-Reply-To: <1f2ed5cd040915093461edc110@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Danny Ayers wrote: > First of all I'm not at all sure categories have a place in the > protocol at all, or for that matter anywhere in core Atom. > Categorization on the web is a hard problem with different solutions > being more appropriate in some circumstances than others. I'm not too psyched about it either, but many tools and the MetaWeblogAPI support them. > I'm a big fan of DAGs, but I think > even such a restriction is a step too far. I go along with the idea of > the servers using whatever model they wish. Do you consider the following model too restrictive? I'm not sure we can be any looser. Category - URI - many: memberOfURIs - many: memberURIs (can be entries or categories) - name/title Robert Sayre From owner-atom-protocol Wed Sep 15 11:10:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIAbJ8027775 for ; Wed, 15 Sep 2004 11:10:37 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIAb6h027774 for atom-protocol-skb; Wed, 15 Sep 2004 11:10:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIAafS027765 for ; Wed, 15 Sep 2004 11:10:37 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so253279rnk for ; Wed, 15 Sep 2004 11:10:34 -0700 (PDT) Received: by 10.38.70.19 with SMTP id s19mr1156875rna; Wed, 15 Sep 2004 11:10:33 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Wed, 15 Sep 2004 11:10:33 -0700 (PDT) Message-ID: <3f1451f504091511101115c5df@mail.gmail.com> Date: Wed, 15 Sep 2004 14:10:33 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Ezra Cooper Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 14 Sep 2004 16:43:22 -0700, Ezra Cooper wrote: > Maybe this is the same as the PostURI; maybe when you GET the PostURI, > you get this feed-level resource. > To rephrase that, suppose the PostURI is really a "weblog resource" or > an "editable feed resource." When you POST to that resource, you're > posting a new entry into the feed. When you GET that resource, you get > the feed-level metadata (or even the full feed). This resource would > also be the place where feed configuration extensions could be made. > > This would also be a place to offer links for discoverability of the > other "lists": like the list of available categories. Currently, in > TypePad, to get a list of available categories, you GET a URL ending in > "/t/atom/weblog/blog_id=/svc=categories". Rather than set a > standard form for this URL, I'm proposing it be chosen by the server > and listed in the uber-discoverability resource which can be GOT at the > PostURI. > > I like the idea of hiding most of the discoverability links at this > feed-level resource, as opposed to dragging them down the front street > on the HTML page. I would offer the Introspection file as a good place to store all such links. The Introspection file was part of the protocol at one point, then dropped in the name of 'simplifying' the protocol. We should consider bringing it back. Note that the Introspection file had it's own URI that was seperate from the other protcol URIs. http://bitworking.org/projects/atom/draft-gregorio-05.html#rfc.section.4.1 http://bitworking.org/news/Extending_the_AtomAPI -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 15 11:23:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FINgjN029152 for ; Wed, 15 Sep 2004 11:23:42 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FINgBc029151 for atom-protocol-skb; Wed, 15 Sep 2004 11:23:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FINf6Y029137 for ; Wed, 15 Sep 2004 11:23:41 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8FINb0S008305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Sep 2004 11:23:37 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C7eRN-0006HC-9A by authid for ; Wed, 15 Sep 2004 11:23:37 -0700 Date: Wed, 15 Sep 2004 11:23:37 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040915182337.GC9997@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f504091511101115c5df@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 15, 2004 at 02:10:33PM -0400, Joe Gregorio wrote: >... > I would offer the Introspection file as a good place to > store all such links. The Introspection file was part of > the protocol at one point, then dropped in the > name of 'simplifying' the protocol. We should > consider bringing it back. How about we fall back to saying: what data do we need to represent? *Then* we talk about how to get it. You say "a new resource", and I say "WebDAV properties." But I'd rather defer that argument :-), and just figure out all the bits we're trying to represent on the server. Cheers, -g From owner-atom-protocol Wed Sep 15 11:31:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIVTwu029734 for ; Wed, 15 Sep 2004 11:31:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIVT0h029733 for atom-protocol-skb; Wed, 15 Sep 2004 11:31:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIVTgg029722 for ; Wed, 15 Sep 2004 11:31:29 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 1A11D47BF9 for ; Wed, 15 Sep 2004 11:30:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <3f1451f504091511101115c5df@mail.gmail.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit From: Ezra Cooper Subject: Introspection Date: Wed, 15 Sep 2004 11:32:01 -0700 To: atom-protocol@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:10 AM, Joe Gregorio wrote: > Note that the Introspection file had it's own URI that > was seperate from the other protcol URIs. Just curious, if it weren't for the history, what would be the advantage of separating the PostURI from the introspection URI? The "feed" is a resource; in one case we're posting to it, in another case we're getting information about it. Is it the distinction between "getting a representation of" and "getting data about"? Ezra From owner-atom-protocol Wed Sep 15 11:33:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIXQYa029916 for ; Wed, 15 Sep 2004 11:33:26 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIXQT8029915 for atom-protocol-skb; Wed, 15 Sep 2004 11:33:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIXPFl029907 for ; Wed, 15 Sep 2004 11:33:25 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 53C5647BF7 for ; Wed, 15 Sep 2004 11:32:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-protocol@imc.org From: Ezra Cooper Subject: Re: Categories Date: Wed, 15 Sep 2004 11:33:57 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 9:34 AM, Danny Ayers wrote: > First of all I'm not at all sure categories have a place in the > protocol at all, or for that matter anywhere in core Atom. Outside of entries/feeds, they seem like the next most important thing to get interoperation for. I only shy away from allowing multiple parents because it gets more complicated at that point. Do we select one parent as the "primary" parent, in order to provide a canonical path from root to leaf? Can we allow cycles as long as there is a simple path to the root? I do worry about modeling this too specifically and being too restrictive in the long run. If trees aren't general enough, then maybe the simple solution is not to give them structure in the core, but just to give entries a category element and let extensions worry about structure. In that case, I'm still interested in a discoverable list of categories, although certainly some tools won't want to provide that. On Sep 15, 2004, at 9:34 AM, Danny Ayers wrote: > Categorization on the web is a hard problem with different solutions > being more appropriate in some circumstances than others. Agreed; is there a loose element that we can provide that will allow different solutions to be applied via extensions? Can you give some idea how broadly we should be thinking? Ezra From owner-atom-protocol Wed Sep 15 11:38:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIcqE2030468 for ; Wed, 15 Sep 2004 11:38:52 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIcqm3030467 for atom-protocol-skb; Wed, 15 Sep 2004 11:38:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIcpXq030460 for ; Wed, 15 Sep 2004 11:38:51 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8FIcopn003557 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Sep 2004 11:38:50 -0700 In-Reply-To: <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> Content-Transfer-Encoding: 7bit Cc: atom-protocol@imc.org From: steve jenson Subject: Re: Introspection Date: Wed, 15 Sep 2004 11:38:50 -0700 To: Ezra Cooper X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:32 AM, Ezra Cooper wrote: > On Sep 15, 2004, at 11:10 AM, Joe Gregorio wrote: > >> Note that the Introspection file had it's own URI that >> was seperate from the other protcol URIs. > > Just curious, if it weren't for the history, what would be the > advantage of separating the PostURI from the introspection URI? The > "feed" is a resource; in one case we're posting to it, in another case > we're getting information about it. Is it the distinction between > "getting a representation of" and "getting data about"? Because we were not simply introspecting a Blog's capabilities but a User's capabilities. Sorry, I'm joining this conversation late (I just noticed this mailing list) so please let me know if this has already been covered as I don't see this thread in the archive listing. -steve From owner-atom-protocol Wed Sep 15 11:40:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIeB4K030577 for ; Wed, 15 Sep 2004 11:40:11 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIeBtR030576 for atom-protocol-skb; Wed, 15 Sep 2004 11:40:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIeBsv030566 for ; Wed, 15 Sep 2004 11:40:11 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id D6FD647BF7 for ; Wed, 15 Sep 2004 11:39:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-protocol@imc.org From: Ezra Cooper Subject: Fwd: Template IO Date: Wed, 15 Sep 2004 11:40:42 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [forgot to include the list on this last night] On Sep 14, 2004, at 7:35 PM, Robert Sayre wrote: > The output filename seems to be way a to say that resource/collection > A is a view of resource/collection B (the view is probably limited in > quantity, time frame, etc). > > so B --> template --> A > > or > > B --> [input set] --> template --> [output set] --> A > > So the question is whether the input and output selection can be > specified in an interoperable manner. I'm pessimistic, but if the WG > can come to consensus, great. I'm not sure I understand your schematic there, but the element I had in mind would determine what URLs were controlled by the template. So I might write a template that draws single-post pages and I want that template to be used to draw the pages at urls like http://host.com/blog/.html. Or I might want it to appear at http://host.com/blog//.html. This field would determine that schema. I too doubt we could do it in a truly interoperable way. In MT we use most of the generality of the MT template language to determine how the URLs are constructed. I was simply imagining that it could be an arbitrary text field, tagged with a type--the same way the template "content" is not likely to interoperate but can be interpreted by its type. > In other words, I think "output file" is really part of MT's template > format. In WebDAV terms, an extension property. My feeling is that by > leaving this up to MIME, there's space for future standardization work > on templating. That's totally reasonable; it should be an extension if it's not widely useful. Ezra From owner-atom-protocol Wed Sep 15 11:53:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIrTgK031520 for ; Wed, 15 Sep 2004 11:53:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FIrTTG031519 for atom-protocol-skb; Wed, 15 Sep 2004 11:53:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FIrTKH031508 for ; Wed, 15 Sep 2004 11:53:29 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id A5E4547BF7; Wed, 15 Sep 2004 11:52:26 -0700 (PDT) In-Reply-To: <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1003123771 Message-Id: <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> Cc: atom-protocol@imc.org From: Ezra Cooper Subject: Re: Introspection Date: Wed, 15 Sep 2004 11:54:00 -0700 To: steve jenson X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-1003123771 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Sep 15, 2004, at 11:38 AM, steve jenson wrote: > On Sep 15, 2004, at 11:32 AM, Ezra Cooper wrote: >> >> Just curious, if it weren't for the history, what would be the >> advantage of separating the PostURI from the introspection URI? The >> "feed" is a resource; in one case we're posting to it, in another >> case we're getting information about it. Is it the distinction >> between "getting a representation of" and "getting data about"? > > Because we were not simply introspecting a Blog's capabilities but a > User's capabilities. > > Sorry, I'm joining this conversation late (I just noticed this mailing > list) so please let me know if this has already been covered as I > don't see this thread in the archive listing. Sorry, that's my fault: "Introspection" was "Re: ProtocolDataModel issues" I had proposed [1] changing PostURI to be the URI of a resource called the "editable feed." It would include all feed-level metadata, plus the introspection links to other services (category list, other "editable feeds" accessible to the same user, etc.). So, just floating the idea of allowing a GET to the PostURI, returning a document with useful data about the "feed" as a whole, and which is atom-authenticated and thus can include private data for the author. Ezra [1] http://www.imc.org/atom-protocol/mail-archive/msg00015.html --Apple-Mail-1-1003123771 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII On Sep 15, 2004, at 11:38 AM, steve jenson wrote: On Sep 15, 2004, at 11:32 AM, Ezra Cooper wrote: Just curious, if it weren't for the history, what would be the advantage of separating the PostURI from the introspection URI? The "feed" is a resource; in one case we're posting to it, in another case we're getting information about it. Is it the distinction between "getting a representation of" and "getting data about"? Because we were not simply introspecting a Blog's capabilities but a User's capabilities. Sorry, I'm joining this conversation late (I just noticed this mailing list) so please let me know if this has already been covered as I don't see this thread in the archive listing. Sorry, that's my fault: "Introspection" was "Re: ProtocolDataModel issues" I had proposed [1] changing PostURI to be the URI of a resource called the "editable feed." It would include all feed-level metadata, plus the introspection links to other services (category list, other "editable feeds" accessible to the same user, etc.).Helvetica So, just floating the idea of allowing a GET to the PostURI, returning a document with useful data about the "feed" as a whole, and which is atom-authenticated and thus can include private data for the author. Ezra [1] http://www.imc.org/atom-protocol/mail-archive/msg00015.html --Apple-Mail-1-1003123771-- From owner-atom-protocol Wed Sep 15 12:30:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJU3gQ034416 for ; Wed, 15 Sep 2004 12:30:03 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJU3L0034414 for atom-protocol-skb; Wed, 15 Sep 2004 12:30:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJU28k034401 for ; Wed, 15 Sep 2004 12:30:02 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 40DE67C2E7; Wed, 15 Sep 2004 22:19:50 +0200 (CEST) Date: Wed, 15 Sep 2004 21:33:21 +0200 To: "Ezra Cooper" Subject: Re: Categories References: Cc: "Atom Protocol" From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper wrote: > Outside of entries/feeds, they seem like the next most important thing > to get interoperation for. I agree. Especially if they were based on a standard categorization system that made sense outside the tiny world of a single weblog system. One such categorization system is the IPTC NewsCode system: > I only shy away from allowing multiple parents because it gets more > complicated at that point. Do we select one parent as the "primary" > parent, in order to provide a canonical path from root to leaf? Can we > allow cycles as long as there is a simple path to the root? I do worry > about modeling this too specifically and being too restrictive in the > long run. IPTC has a pretty good solution to this. All categories are given a unique number. ŤSportť have the number '15000000'. All sub-categories of Ťsportť will start with '15XXXXXX', and each sub-category ending with '0' is possibly a parent category, e.g. Ťaero and aviation sportť which has the number '15001000'. All sub-categories of Ťaero and aviation sportť will start with '15001XXX'; e.g. Ťparachutingť which has the number '15001001'. This system is pretty intricate, but very well thought out. And it works. I've worked with for a while, and although the learning curve was a bit steep, using it now solves a lot of problems. No need to parse strings and do awkward string comparison. There exist a system, and it is easy to follow. The nice thing is that all categories in IPTC can, and are meant to, be combined. So, you can add '15001001', '15000012', '15000002' and '08003002' to your entry, which then means you're writing something about senior, celebrity, parachuting women. The implementation and syntax details aren't very interesting, but they could look like this: -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Wed Sep 15 12:36:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJah2S034905 for ; Wed, 15 Sep 2004 12:36:43 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJahMX034904 for atom-protocol-skb; Wed, 15 Sep 2004 12:36:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJagfa034898 for ; Wed, 15 Sep 2004 12:36:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7fa6-0000Ij-8p; Wed, 15 Sep 2004 19:36:42 +0000 Message-ID: <414899CA.3010405@franklinmint.fm> Date: Wed, 15 Sep 2004 15:36:42 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Ezra Cooper , Atom Protocol Subject: Re: Categories References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Asbjřrn Ulsberg wrote: > > On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper wrote: > >> Outside of entries/feeds, they seem like the next most important >> thing to get interoperation for. > > > I agree. Especially if they were based on a standard categorization > system that made sense outside the tiny world of a single weblog > system. One such categorization system is the IPTC NewsCode system: > -1. So far we have avoided semantics like that. There is no precedent in weblog systems for that. Everyone makes their own tiny little world. If there's a need for coordination, a URI can be agreed upon. Robert Sayre From owner-atom-protocol Wed Sep 15 12:45:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJjv0S035761 for ; Wed, 15 Sep 2004 12:45:57 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJjvqk035760 for atom-protocol-skb; Wed, 15 Sep 2004 12:45:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJjusf035752 for ; Wed, 15 Sep 2004 12:45:56 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so268115rnk for ; Wed, 15 Sep 2004 12:45:55 -0700 (PDT) Received: by 10.38.70.19 with SMTP id s19mr1238831rna; Wed, 15 Sep 2004 12:45:54 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Wed, 15 Sep 2004 12:45:54 -0700 (PDT) Message-ID: <3f1451f504091512451341af68@mail.gmail.com> Date: Wed, 15 Sep 2004 15:45:54 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Greg Stein Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: <20040915182337.GC9997@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 11:23:37 -0700, Greg Stein wrote: > > On Wed, Sep 15, 2004 at 02:10:33PM -0400, Joe Gregorio wrote: > >... > > I would offer the Introspection file as a good place to > > store all such links. The Introspection file was part of > > the protocol at one point, then dropped in the > > name of 'simplifying' the protocol. We should > > consider bringing it back. > > How about we fall back to saying: what data do we need to represent? > > *Then* we talk about how to get it. You say "a new resource", and I say > "WebDAV properties." But I'd rather defer that argument :-), and just > figure out all the bits we're trying to represent on the server. I'll give the 'data model' idea a little more time, but I honestly haven't seen a lot of traffic on this list and we might need to make the discussion a bit more concrete to get more participation. -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 15 12:54:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJsZ98036879 for ; Wed, 15 Sep 2004 12:54:35 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJsZUp036878 for atom-protocol-skb; Wed, 15 Sep 2004 12:54:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJsY5w036824 for ; Wed, 15 Sep 2004 12:54:35 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id AF3047C2E7; Wed, 15 Sep 2004 22:44:22 +0200 (CEST) Date: Wed, 15 Sep 2004 21:57:59 +0200 To: mint@franklinmint.fm Subject: Re: Categories Cc: "Atom Protocol" References: <414899CA.3010405@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <414899CA.3010405@franklinmint.fm> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 15:36:42 -0400, Robert Sayre wrote: >> I agree. Especially if they were based on a standard categorization >> system that made sense outside the tiny world of a single weblog >> system. One such categorization system is the IPTC NewsCode system: > > -1. So far we have avoided semantics like that. There is no precedent in > weblog systems for that. Why should weblog systems and their current practice set the standard for how Atom is going to be modeled, and thus, used? > Everyone makes their own tiny little world. If there's a need for > coordination, a URI can be agreed upon. Why can't we use IPTC? Why is it better to grow our own system? -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Wed Sep 15 14:30:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FLUUuX049343 for ; Wed, 15 Sep 2004 14:30:30 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FLUT4q049342 for atom-protocol-skb; Wed, 15 Sep 2004 14:30:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FLUTV3049329 for ; Wed, 15 Sep 2004 14:30:29 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8FLUDNI005451 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Sep 2004 14:30:13 -0700 In-Reply-To: <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DB1CFB8-075E-11D9-99F1-000A95B09B46@google.com> Content-Transfer-Encoding: 7bit Cc: atom-protocol@imc.org From: steve jenson Subject: Re: Introspection Date: Wed, 15 Sep 2004 14:30:13 -0700 To: Ezra Cooper X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:54 AM, Ezra Cooper wrote: > I had proposed [1] changing PostURI to be the URI of a resource called > the "editable feed." It would include all feed-level metadata, plus > the introspection links to other services (category list, other > "editable feeds" accessible to the same user, etc.). > > So, just floating the idea of allowing a GET to the PostURI, returning > a document with useful data about the "feed" as a whole, and which is > atom-authenticated and thus can include private data for the author. > > Ezra > > [1] http://www.imc.org/atom-protocol/mail-archive/msg00015.html Yeah, this is currently what Blogger does. our service.feed and service.post URIs are the same and the service.feed URI returns data that's not necessarily in your public feed. I don't see a need for those two URIs to be separate, either. The symmetry seemed clear. Having more private data in there would be even better. My comment was that there's room for a user-level Introspection file as well as blog level. -steve From owner-atom-protocol Wed Sep 15 15:49:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FMnL39055277 for ; Wed, 15 Sep 2004 15:49:21 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FMnLHM055276 for atom-protocol-skb; Wed, 15 Sep 2004 15:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FMnLrT055267 for ; Wed, 15 Sep 2004 15:49:21 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 7319B47BF7; Wed, 15 Sep 2004 15:48:19 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> Cc: "Atom Protocol" From: Ezra Cooper Subject: Re: Categories Date: Wed, 15 Sep 2004 15:49:54 -0700 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8FMnLrT055271 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 12:33 PM, Asbjřrn Ulsberg wrote: > On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper > wrote: > >> Outside of entries/feeds, they seem like the next most important >> thing to get interoperation for. > > I agree. Especially if they were based on a standard categorization > system that made sense outside the tiny world of a single weblog > system. One such categorization system is the IPTC NewsCode system: > > I'm also opposed to standardizing on one universal set of categories. How could we agree on the one that suits everyone's needs? If you, as an author, want to refer to some external category system, I think that's your business. Perhaps an attribute would allow you to tag your entry's category as referring to a certain hierarchy? My model for categories is that authors determine their own categorization system, and that categories are pre-established and long-lived. This is different from "tags" in the del.icio.us/Flickr model, which can be created on the fly. As such, I'm in favor of having modeling categories in some very general way and allowing clients to GET and PUT them to manipulate a hierarchy that's local to the Atom server. Ezra From owner-atom-protocol Wed Sep 15 16:07:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FN76nA056997 for ; Wed, 15 Sep 2004 16:07:06 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FN76YB056996 for atom-protocol-skb; Wed, 15 Sep 2004 16:07:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FN75wc056990 for ; Wed, 15 Sep 2004 16:07:05 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C7irh-0001oU-JN; Wed, 15 Sep 2004 23:07:05 +0000 Message-ID: <4148CB25.8070209@franklinmint.fm> Date: Wed, 15 Sep 2004 19:07:17 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Greg Stein , atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <3f1451f504091512451341af68@mail.gmail.com> In-Reply-To: <3f1451f504091512451341af68@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe Gregorio wrote: > On Wed, 15 Sep 2004 11:23:37 -0700, Greg Stein wrote: > >>How about we fall back to saying: what data do we need to represent? >> >>*Then* we talk about how to get it. You say "a new resource", and I say >>"WebDAV properties." But I'd rather defer that argument :-), and just >>figure out all the bits we're trying to represent on the server. > > > I'll give the 'data model' idea a little more time, but > I honestly haven't seen a lot of traffic on this list > and we might need to make the discussion a bit more > concrete to get more participation. What data is represented by the introspection file? Robert Sayre From owner-atom-protocol Wed Sep 15 16:44:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FNilkk059119 for ; Wed, 15 Sep 2004 16:44:47 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FNilvj059118 for atom-protocol-skb; Wed, 15 Sep 2004 16:44:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FNikhb059110 for ; Wed, 15 Sep 2004 16:44:46 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so31759rnl for ; Wed, 15 Sep 2004 16:44:43 -0700 (PDT) Received: by 10.38.74.77 with SMTP id w77mr1043705rna; Wed, 15 Sep 2004 16:44:43 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Wed, 15 Sep 2004 16:44:43 -0700 (PDT) Message-ID: <3f1451f5040915164425052909@mail.gmail.com> Date: Wed, 15 Sep 2004 19:44:43 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Categories Cc: Ezra Cooper , Atom Protocol In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8FNikhb059113 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 21:33:21 +0200, Asbjřrn Ulsberg wrote: > > On Wed, 15 Sep 2004 11:33:57 -0700, Ezra Cooper wrote: > > > Outside of entries/feeds, they seem like the next most important thing > > to get interoperation for. > > I agree. Especially if they were based on a standard categorization system > that made sense outside the tiny world of a single weblog system. One such > categorization system is the IPTC NewsCode system: I believe we need to provide a 'spot' for categorization information to go, and we should make sure that certain popular categorization systems 'fit' in the spot we make, but I don't believe we should bless one such system as the one and only system to use with Atom. -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Wed Sep 15 18:48:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G1mRs8074363 for ; Wed, 15 Sep 2004 18:48:27 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G1mR26074362 for atom-protocol-skb; Wed, 15 Sep 2004 18:48:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G1mQHa074351 for ; Wed, 15 Sep 2004 18:48:26 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8G1mW53012075 for ; Wed, 15 Sep 2004 19:48:32 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I44000PX2CVN5@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Wed, 15 Sep 2004 19:48:32 -0600 (MDT) Received: from [10.242.56.100] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4400KTW2CU3Q@mail.sun.net> for atom-protocol@imc.org; Wed, 15 Sep 2004 19:48:31 -0600 (MDT) Date: Wed, 15 Sep 2004 18:48:29 -0700 From: Tim Bray Subject: Re: Categories In-reply-to: To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Atom Protocol , Ezra Cooper Message-id: <81ED1FDD-0782-11D9-854B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8G1mQHa074357 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 12:33 PM, Asbjřrn Ulsberg wrote: >> Outside of entries/feeds, they seem like the next most important >> thing to get interoperation for. > > I agree. Especially if they were based on a standard categorization > system that made sense outside the tiny world of a single weblog > system. One such categorization system is the IPTC NewsCode system: > > -1. Not just on this, on any Universal Taxonomy of Everything for Atom. -Tim From owner-atom-protocol Wed Sep 15 19:08:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G28oTj076284 for ; Wed, 15 Sep 2004 19:08:50 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G28omT076283 for atom-protocol-skb; Wed, 15 Sep 2004 19:08:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G28nBa076274 for ; Wed, 15 Sep 2004 19:08:49 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8G28t53018962 for ; Wed, 15 Sep 2004 20:08:55 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I44000QN3AUNZ@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Wed, 15 Sep 2004 20:08:55 -0600 (MDT) Received: from [10.242.56.100] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4400KCF3AT3N@mail.sun.net> for atom-protocol@imc.org; Wed, 15 Sep 2004 20:08:54 -0600 (MDT) Date: Wed, 15 Sep 2004 19:08:53 -0700 From: Tim Bray Subject: Re: ProtocolDataModel issues In-reply-to: <20040915182337.GC9997@google.com> To: Greg Stein Cc: atom-protocol@imc.org Message-id: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:23 AM, Greg Stein wrote: > How about we fall back to saying: what data do we need to represent? > > *Then* we talk about how to get it. OK, the answer is: the data that's specified in the Atom format specification (not quite 100% settled). Fortunately, that not only specifies the data but the representation. Furthermore, we know the operations we want to accomplish on that data: create, update, and delete. Furthermore we have a substantial body of work already accomplished, written up at http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt If people want to do model-level work to deepen their understanding, that's fine. But to me it doesn't become real until you can start talking about how you're going to replace/modify the existing spec. Sooner is better. -Tim From owner-atom-protocol Wed Sep 15 22:52:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G5qQLk011156 for ; Wed, 15 Sep 2004 22:52:26 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G5qQgK011155 for atom-protocol-skb; Wed, 15 Sep 2004 22:52:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G5qP1w011086 for ; Wed, 15 Sep 2004 22:52:26 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id E847D7C2E7; Thu, 16 Sep 2004 08:42:07 +0200 (CEST) Date: Thu, 16 Sep 2004 07:54:53 +0200 To: "Ezra Cooper" Subject: Re: Categories Cc: "Atom Protocol" References: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 15:49:54 -0700, Ezra Cooper wrote: > I'm also opposed to standardizing on one universal set of categories. > How could we agree on the one that suits everyone's needs? If you don't find a category that fits your need in IPTC, you have a seriously awkward interest. > If you, as an author, want to refer to some external category system, > I think that's your business. Perhaps an attribute would allow you > to tag your entry's category as referring to a certain hierarchy? Am I the only one who sees benefits from knowing, universally, what an entry is about? > My model for categories is that authors determine their own > categorization system, and that categories are pre-established and > long-lived. Who is this category system for? The author? It's definately not for anything half- or full-automatic classification system. It makes it impossible for a client to choose in his client that he is interested in X, Y and Z, and then get entries that actually only match X, Y and Z. -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Wed Sep 15 23:00:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G60vbS016516 for ; Wed, 15 Sep 2004 23:00:57 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G60voI016515 for atom-protocol-skb; Wed, 15 Sep 2004 23:00:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G60uOZ016472 for ; Wed, 15 Sep 2004 23:00:56 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id E7EC17C2E7; Thu, 16 Sep 2004 08:50:43 +0200 (CEST) To: "Joe Gregorio" Cc: "Atom Protocol" Subject: Re: Categories References: <3f1451f5040915164425052909@mail.gmail.com> Message-ID: Date: Thu, 16 Sep 2004 08:03:32 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <3f1451f5040915164425052909@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 19:44:43 -0400, Joe Gregorio wrote: > I believe we need to provide a 'spot' for categorization information > to go, and we should make sure that certain popular categorization > systems 'fit' in the spot we make, but I don't believe we should > bless one such system as the one and only system to use with > Atom. Okay, that sounds reasonable. It wouldn't hurt to spread the good word about IPTC either, so it would be possible to automatically recognize what entries really were about, without having a human reading through the whole entry first. But I guess this recommendation could go somewhere else than in the specification. -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Wed Sep 15 23:25:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G6PYFi025190 for ; Wed, 15 Sep 2004 23:25:34 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G6PYFc025189 for atom-protocol-skb; Wed, 15 Sep 2004 23:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G6PXU1025142 for ; Wed, 15 Sep 2004 23:25:34 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id C62AD7C2E7; Thu, 16 Sep 2004 09:15:12 +0200 (CEST) To: "Tim Bray" Cc: "Atom Protocol" , "Ezra Cooper" Subject: Re: Categories References: <81ED1FDD-0782-11D9-854B-000A95A51C9E@sun.com> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 16 Sep 2004 08:28:05 +0200 In-Reply-To: <81ED1FDD-0782-11D9-854B-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 18:48:29 -0700, Tim Bray wrote: >> > > -1. Not just on this, on any Universal Taxonomy of Everything for Atom. Are you -1 to Dublin Core as a concept (for Atom) as well, then? -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Wed Sep 15 23:50:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G6o96T033556 for ; Wed, 15 Sep 2004 23:50:09 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G6o9MB033554 for atom-protocol-skb; Wed, 15 Sep 2004 23:50:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G6o8Mi033544 for ; Wed, 15 Sep 2004 23:50:08 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8G6o753021404 for ; Thu, 16 Sep 2004 00:50:07 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4400L92GBJ5C@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Thu, 16 Sep 2004 00:50:07 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4400KP0GBI3Q@mail.sun.net> for atom-protocol@imc.org; Thu, 16 Sep 2004 00:50:07 -0600 (MDT) Date: Wed, 15 Sep 2004 23:50:04 -0700 From: Tim Bray Subject: Re: Categories In-reply-to: To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Atom Protocol , Ezra Cooper Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <81ED1FDD-0782-11D9-854B-000A95A51C9E@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8G6o8Mi033547 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 15, 2004, at 11:28 PM, Asbjřrn Ulsberg wrote: >> -1. Not just on this, on any Universal Taxonomy of Everything for >> Atom. > > Are you -1 to Dublin Core as a concept (for Atom) as well, then? I'm not a DC expert but I didn't think it came with taxonomies. It gave you a place to put your classifications, but didn't say what you should put there. -Tim From owner-atom-protocol Thu Sep 16 05:51:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GCpHnG033148 for ; Thu, 16 Sep 2004 05:51:17 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GCpH9W033147 for atom-protocol-skb; Thu, 16 Sep 2004 05:51:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GCpGjM033140 for ; Thu, 16 Sep 2004 05:51:16 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so124774rnk for ; Thu, 16 Sep 2004 05:51:07 -0700 (PDT) Received: by 10.38.125.33 with SMTP id x33mr1265087rnc; Thu, 16 Sep 2004 05:51:07 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Thu, 16 Sep 2004 05:51:07 -0700 (PDT) Message-ID: <14be96d30409160551605f595a@mail.gmail.com> Date: Thu, 16 Sep 2004 08:51:07 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Categories Cc: Atom Protocol In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8GCpHjM033142 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 07:54:53 +0200, Asbjřrn Ulsberg wrote: > > On Wed, 15 Sep 2004 15:49:54 -0700, Ezra Cooper wrote: > > > I'm also opposed to standardizing on one universal set of categories. > > How could we agree on the one that suits everyone's needs? > > If you don't find a category that fits your need in IPTC, you have a > seriously awkward interest. I have a category for accessibility. They don't have a category for accessibility. They have a category for "disabled", defined as "Being incapacitated either physically, emotionally or mentally." I find this subtlely offensive. I have a category for Zen Buddhism. They don't have a category for Zen Buddhism. They have a category for "Buddhism", but not specific categories for different types. (They *do* have specific categories for Protestant, Lutheran, Reformed, Anglican, Methodist, Baptist, Mennonite, Mormon, Roman Catholic, Old Catholic, and Orthodoxy.) I have separate categories for Apple, Python, markup, web services, and CSS. Their computer-related categories are limited to computing and information technology, hardware, networking, satellite technology, semiconductors and active components, software, telecommunication equipment, telecommunication service, and security. Where do you propose I pigeonhole my categories? All categorization systems have biases and limitations, based on the worldview and needs of their creators. This one doesn't work for me, and no single categorization system will ever work for everyone. -- Cheers, -Mark From owner-atom-protocol Thu Sep 16 09:23:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GGNp8u050071 for ; Thu, 16 Sep 2004 09:23:51 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GGNp51050070 for atom-protocol-skb; Thu, 16 Sep 2004 09:23:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GGNpso050059 for ; Thu, 16 Sep 2004 09:23:51 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA08851 for ; Thu, 16 Sep 2004 09:23:47 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA17398 for ; Thu, 16 Sep 2004 09:23:46 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 16 Sep 2004 09:23:46 -0700 Received: from [192.168.150.112] (diva [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i8GGNjlB001122 for ; Thu, 16 Sep 2004 09:23:46 -0700 (PDT) Date: Thu, 16 Sep 2004 09:23:59 -0700 From: Walter Underwood To: Atom Protocol Subject: Re: Categories Message-ID: <7E2C8E7B263F7B96BD831BB8@diva.verity.com> In-Reply-To: References: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8GGNpso050064 Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --On Thursday, September 16, 2004 07:54:53 AM +0200 Asbjřrn Ulsberg wrote: > On Wed, 15 Sep 2004 15:49:54 -0700, Ezra Cooper wrote: > >> I'm also opposed to standardizing on one universal set of categories. >> How could we agree on the one that suits everyone's needs? > > If you don't find a category that fits your need in IPTC, you have a > seriously awkward interest. Really? Does IPTC distinguish betwen emo and electronica? Between RDF and Topic Maps? Between wire and optical Time Domain Reflectometers? Vegetarian and vegan? Classification schemes are about access to a particular kind of object: books, news articles, technical reports, music reviews, recipies, the list goes on and on. Distinctions may be critical in one domain and meaningless in another. Useful for one kind of searcher (physicians) and useless for another (patients). Even huge schemes like Library of Congress Subject Headings, with a half million categories, are useless for fairly normal distinctions within technical disciplines, like Atom vs RSS. Taxonomies are tools for access. Use the right tool for the job. Universal organizations of knowlege can be filed next to perpetual motion machines. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-protocol Thu Sep 16 09:26:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GGQx0x050368 for ; Thu, 16 Sep 2004 09:26:59 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GGQxWe050367 for atom-protocol-skb; Thu, 16 Sep 2004 09:26:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8GGQw3r050360 for ; Thu, 16 Sep 2004 09:26:58 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 31005 invoked from network); 16 Sep 2004 16:26:57 -0000 Received: from host81-130-14-17.in-addr.btopenworld.com (HELO ?192.168.254.19?) (81.130.14.17) by relay.pair.com with SMTP; 16 Sep 2004 16:26:57 -0000 X-pair-Authenticated: 81.130.14.17 Message-ID: <4149BED2.2040506@internetalchemy.org> Date: Thu, 16 Sep 2004 17:26:58 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 0.8 (Windows/20040908) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Protocol Subject: Re: Categories References: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> <14be96d30409160551605f595a@mail.gmail.com> In-Reply-To: <14be96d30409160551605f595a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 16/09/2004 13:51, Mark Pilgrim wrote: > All categorization systems have biases and limitations, based on the > worldview and needs of their creators. This one doesn't work for me, > and no single categorization system will ever work for everyone. +1 Ian From owner-atom-protocol Thu Sep 16 10:17:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GHHOak055500 for ; Thu, 16 Sep 2004 10:17:24 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GHHOSA055499 for atom-protocol-skb; Thu, 16 Sep 2004 10:17:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GHHNv9055492 for ; Thu, 16 Sep 2004 10:17:24 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so25166rnb for ; Thu, 16 Sep 2004 10:17:22 -0700 (PDT) Received: by 10.38.8.54 with SMTP id 54mr75475rnh; Thu, 16 Sep 2004 10:17:22 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Thu, 16 Sep 2004 10:17:22 -0700 (PDT) Message-ID: <1f2ed5cd04091610173cee01d8@mail.gmail.com> Date: Thu, 16 Sep 2004 19:17:22 +0200 From: Danny Ayers Reply-To: Danny Ayers To: steve jenson Subject: Re: Introspection Cc: Ezra Cooper , atom-protocol@imc.org In-Reply-To: <6DB1CFB8-075E-11D9-99F1-000A95B09B46@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <889A6050-0745-11D9-9EEA-000A95CFF6CC@sixapart.com> <7C93D8BC-0746-11D9-99F1-000A95B09B46@google.com> <9B34897E-0748-11D9-9EEA-000A95CFF6CC@sixapart.com> <6DB1CFB8-075E-11D9-99F1-000A95B09B46@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Sep 2004 14:30:13 -0700, steve jenson wrote: Glad to see you here Steve. This side-list has been (relatively) quiet, you've not missed much. > Yeah, this is currently what Blogger does. our service.feed and > service.post URIs are the same and the service.feed URI returns data > that's not necessarily in your public feed. I don't see a need for > those two URIs to be separate, either. Glancing at 6@ The symmetry seemed clear. Yep, it does look more elegant that way, and I can't myself think of any use cases that would need to discriminate. But it may be that in certain environments it may be easier to keep the two separate - e.g. I can imagine using a servlet for service.post and a (generated) static file for service.feed. Dunno. Maybe combine it and see if anyone screams? Having more private data in there would be > even better. Yes, I like the general idea a lot. > My comment was that there's room for a user-level Introspection file as > well as blog level. Yep. I'd think some basic access control/rights would be needed too - any thoughts on how this could be simply specified but versatile enough to cover most likely usage? How're things like this done at Blogger at present? Cheers, Danny. [1] http://sixapart.com/developers/atom/typepad/ -- http://dannyayers.com From owner-atom-protocol Thu Sep 16 10:25:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GHPDAW056256 for ; Thu, 16 Sep 2004 10:25:13 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GHPDjS056255 for atom-protocol-skb; Thu, 16 Sep 2004 10:25:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GHPCSC056245 for ; Thu, 16 Sep 2004 10:25:12 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> Date: Thu, 16 Sep 2004 10:24:01 -0700 To: atom-protocol@imc.org From: Paul Hoffman / IMC Subject: Re: ProtocolDataModel issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:08 PM -0700 9/15/04, Tim Bray wrote: >On Sep 15, 2004, at 11:23 AM, Greg Stein wrote: > >>How about we fall back to saying: what data do we need to represent? >> >>*Then* we talk about how to get it. > >OK, the answer is: the data that's specified in the Atom format >specification (not quite 100% settled). Fortunately, that not only >specifies the data but the representation. Furthermore, we know the >operations we want to accomplish on that data: create, update, and >delete. Furthermore we have a substantial body of work already >accomplished, written up at >http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt > >If people want to do model-level work to deepen their understanding, >that's fine. But to me it doesn't become real until you can start >talking about how you're going to replace/modify the existing spec. >Sooner is better. -Tim Said a different way, the WG is waiting for this design team to specify the protocol for the work the WG is doing *today*. I think I understand some of where the modelling that is being discussed is going, but it is not relevant to the current issue of "how do I { verb1 | verb2 | ... } this Atom { entry | feed }". Is there a concern that if we answer that question now, we will limit ourselves for other things that will later go into the model? If so, then we need some extensibility in the answer. If that is impossible to do without more model designing, OK, but let's not spend too much time out in the weeds without helping the WG. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-protocol Thu Sep 16 10:38:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GHcOlw057372 for ; Thu, 16 Sep 2004 10:38:24 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GHcOlE057371 for atom-protocol-skb; Thu, 16 Sep 2004 10:38:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GHcNOp057355; Thu, 16 Sep 2004 10:38:23 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C80D7-0001mf-Aa; Thu, 16 Sep 2004 17:38:21 +0000 Message-ID: <4149CF99.3060700@franklinmint.fm> Date: Thu, 16 Sep 2004 13:38:33 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman / IMC wrote: > > the WG is waiting for this design team to specify > the protocol for the work the WG is doing *today*. I think I understand > some of where the modelling that is being discussed is going, but it is > not relevant to the current issue of "how do I { verb1 | verb2 | ... } > this Atom { entry | feed }". > I'm a little lost here. Where is the list of well-defined actions the WG doesn't know how to do and why can't they can't go in http://www.intertwingly.net/wiki/pie/ProtocolDataModel If they are that obvious, it shouldn't take long to write them down. > Is there a concern that if we answer that question now, we will limit > ourselves for other things that will later go into the model? If so, > then we need some extensibility in the answer. If that is impossible to > do without more model designing, OK, but let's not spend too much time > out in the weeds without helping the WG. Both proposals for the creation of this list said the "initial topic for discussion is the needed actions for the Atom protocol." Robert Sayre From owner-atom-protocol Thu Sep 16 11:16:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GIGrWv060986 for ; Thu, 16 Sep 2004 11:16:53 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GIGr6l060985 for atom-protocol-skb; Thu, 16 Sep 2004 11:16:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GIGrpd060972 for ; Thu, 16 Sep 2004 11:16:53 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8GIGnaV002260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 11:16:49 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C80oL-0001Oy-Ia by authid ; Thu, 16 Sep 2004 11:16:49 -0700 Date: Thu, 16 Sep 2004 11:16:49 -0700 From: Greg Stein To: Tim Bray Cc: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040916181649.GD9997@google.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 15, 2004 at 07:08:53PM -0700, Tim Bray wrote: > > On Sep 15, 2004, at 11:23 AM, Greg Stein wrote: > > >How about we fall back to saying: what data do we need to represent? > > > >*Then* we talk about how to get it. > > OK, the answer is: the data that's specified in the Atom format > specification (not quite 100% settled). Fortunately, that not only > specifies the data but the representation. Furthermore, we know the It specifies *a* representation, and one that I do not think is well-suited for manipulation via HTTP. We are also missing things like "given this front page of a blog (in HTML), where is the feed?" I would answer that question with a few points: * I would state that the page has a property named "feed" in some TBD namespace. * the value of the property is an absolute URI * a PROPFIND on that page would return that property Other people might say, "put that into a element on the page". Great. That is another form of protocol: GET the page, rather than PROPFIND it. But the point is that while we might have *some* of the data, we don't have it all. Further, because the feed representation is one big glom, I don't think it is well-suited to discussion about the protocol items around it. What if I want just one entry? Where do I modify that entry? Does that entry have an associated post page? What index page(s) does it appear on? If I have a resource representing the entry, what blog is it associated with? How do I then find that blog's front page? Its feed? Protocols are about answering those questions. I think the statement, "[the feed] not only specifies the data but the representation" is *very* misleading. It is just not that simple. > operations we want to accomplish on that data: create, update, and > delete. Furthermore we have a substantial body of work already > accomplished, written up at > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt Sure, I know about that, but it needs a lot of work. We shouldn't be writing a protocol around URIs, it should be around *resources*. URIs just tell us where they are, but it is the resources that we operate on. That draft needs work, and I believe that doing it right requires a proper model of what we're working on. > If people want to do model-level work to deepen their understanding, > that's fine. But to me it doesn't become real until you can start > talking about how you're going to replace/modify the existing spec. > Sooner is better. -Tim Well, the goal *is* to replace/modify the spec; in my mind, at least. And I don't think it is right for you to try and cut short the discussion by saying "oh, but we already have that", when "that" doesn't really help us to talk about the protocol. Cheers, -g From owner-atom-protocol Thu Sep 16 11:28:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GIS81i061824 for ; Thu, 16 Sep 2004 11:28:08 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GIS8UU061823 for atom-protocol-skb; Thu, 16 Sep 2004 11:28:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no ([213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GIS7HS061810 for ; Thu, 16 Sep 2004 11:28:08 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id B58AB7C2EC; Thu, 16 Sep 2004 21:17:40 +0200 (CEST) To: "Mark Pilgrim" Cc: "Atom Protocol" Subject: Re: Categories References: <8F5133F0-0769-11D9-9EEA-000A95CFF6CC@sixapart.com> <14be96d30409160551605f595a@mail.gmail.com> Message-ID: Date: Thu, 16 Sep 2004 20:30:48 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <14be96d30409160551605f595a@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 08:51:07 -0400, Mark Pilgrim wrote: > All categorization systems have biases and limitations, based on the > worldview and needs of their creators. This one doesn't work for me, > and no single categorization system will ever work for everyone. I agree. As Joe wrote, we should create a general categorization mechanism, but what taxonomy people choose to apply to their entries, is up to them. _I_ would like to recommend a common understandable one, though, but I guess that's my problem. -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Thu Sep 16 17:23:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0N45D090637 for ; Thu, 16 Sep 2004 17:23:04 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H0N4Lx090636 for atom-protocol-skb; Thu, 16 Sep 2004 17:23:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0N31w090628 for ; Thu, 16 Sep 2004 17:23:03 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i8H0MjZP011098; Thu, 16 Sep 2004 20:22:45 -0400 Message-ID: <414A2E23.8050309@intertwingly.net> Date: Thu, 16 Sep 2004 20:21:55 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> In-Reply-To: <20040916181649.GD9997@google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > > We are also missing things like > "given this front page of a blog (in HTML), where is the feed?" http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-00.txt - Sam Ruby From owner-atom-protocol Thu Sep 16 17:33:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0XBRV091115 for ; Thu, 16 Sep 2004 17:33:11 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H0XB4q091114 for atom-protocol-skb; Thu, 16 Sep 2004 17:33:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0X9XF091108 for ; Thu, 16 Sep 2004 17:33:10 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8H0XF53021676 for ; Thu, 16 Sep 2004 18:33:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I45009UMTJEWD@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Thu, 16 Sep 2004 18:33:15 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I45003IUTJEL5@mail.sun.net> for atom-protocol@imc.org; Thu, 16 Sep 2004 18:33:14 -0600 (MDT) Date: Thu, 16 Sep 2004 17:33:13 -0700 From: Tim Bray Subject: Re: ProtocolDataModel issues In-reply-to: <414A2E23.8050309@intertwingly.net> To: Sam Ruby Cc: Greg Stein , atom-protocol@imc.org Message-id: <2911AE3D-0841-11D9-A98F-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: By the way, at XML 2004 (see http://www.xmlconference.org) there's going to be an Atom Hackathon so we better have the model shaken down enough for us to do some protocol debugging there on the spot. That's Nov. 15-19. -Tim [Disclosure: my wife's chairing the conference, Sun's hosting the hackathon, I am like totally conflicted, disregard this message.] From owner-atom-protocol Thu Sep 16 17:36:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0aDvl091280 for ; Thu, 16 Sep 2004 17:36:14 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H0aD9u091279 for atom-protocol-skb; Thu, 16 Sep 2004 17:36:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H0aD4d091267 for ; Thu, 16 Sep 2004 17:36:13 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8H0a9wb032190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 17:36:09 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C86jH-0000ph-Jy by authid ; Thu, 16 Sep 2004 17:35:59 -0700 Date: Thu, 16 Sep 2004 17:35:59 -0700 From: Greg Stein To: Sam Ruby Cc: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040917003559.GA8305@google.com> References: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414A2E23.8050309@intertwingly.net> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 16, 2004 at 08:21:55PM -0400, Sam Ruby wrote: > Greg Stein wrote: > > > >We are also missing things like > >"given this front page of a blog (in HTML), where is the feed?" > > http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-00.txt You're missing the point. That was an example question, and it was rhetorical. (which I'm sure you knew, so I don't understand your reply) The point is: we've got a bunch of data items, but they're in a mish-mash across a number of drafts. We don't have a single, consistent data model defined anywhere such that we can then decide on the protocol for fetching and manipulating them. Personally, I don't want to scrub thru HTML cruft to try and find a feed. I want to PROPFIND it. The response for PROPFIND is well-defined and very well-formed XML. I also have tools to easily do that, unlike trying to extract some element from a page. Cheers, -g From owner-atom-protocol Thu Sep 16 18:12:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1CaHV095657 for ; Thu, 16 Sep 2004 18:12:36 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H1CaNL095656 for atom-protocol-skb; Thu, 16 Sep 2004 18:12:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1CZrm095650 for ; Thu, 16 Sep 2004 18:12:36 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so207979rnl for ; Thu, 16 Sep 2004 18:12:27 -0700 (PDT) Received: by 10.38.81.41 with SMTP id e41mr300699rnb; Thu, 16 Sep 2004 18:12:27 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Thu, 16 Sep 2004 18:12:27 -0700 (PDT) Message-ID: <14be96d304091618125d920554@mail.gmail.com> Date: Thu, 16 Sep 2004 21:12:27 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: ProtocolDataModel issues Cc: Sam Ruby , atom-protocol@imc.org In-Reply-To: <20040917003559.GA8305@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 17:35:59 -0700, Greg Stein wrote: > Personally, I don't want to scrub thru HTML cruft to try and find a feed. > I want to PROPFIND it. The response for PROPFIND is well-defined and very > well-formed XML. I also have tools to easily do that, unlike trying to > extract some element from a page. Oh, well, if it's *very* well-formed XML, then that's a different story. Perhaps you should write up PaceMustBeVeryWellFormed, and enlighten us about the advantages of PROPFIND and very well-formed XML. -- Cheers, -Mark From owner-atom-protocol Thu Sep 16 18:25:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1PDdV096338 for ; Thu, 16 Sep 2004 18:25:13 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H1PDnM096337 for atom-protocol-skb; Thu, 16 Sep 2004 18:25:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1PDZ2096329 for ; Thu, 16 Sep 2004 18:25:13 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8H1PDE3015662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 18:25:13 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C87Uv-0001HZ-FN by authid ; Thu, 16 Sep 2004 18:25:13 -0700 Date: Thu, 16 Sep 2004 18:25:13 -0700 From: Greg Stein To: Mark Pilgrim Cc: atom-protocol@imc.org Subject: Re: ProtocolDataModel issues Message-ID: <20040917012513.GC8305@google.com> References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14be96d304091618125d920554@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 16, 2004 at 09:12:27PM -0400, Mark Pilgrim wrote: > On Thu, 16 Sep 2004 17:35:59 -0700, Greg Stein wrote: > > Personally, I don't want to scrub thru HTML cruft to try and find a feed. > > I want to PROPFIND it. The response for PROPFIND is well-defined and very > > well-formed XML. I also have tools to easily do that, unlike trying to > > extract some element from a page. > > Oh, well, if it's *very* well-formed XML, then that's a different > story. Perhaps you should write up PaceMustBeVeryWellFormed, and > enlighten us about the advantages of PROPFIND and very well-formed > XML. Eh? HTML doesn't have to be well-formed at all. Parsing it is a harder problem then throwing the PROPFIND response body at an XML parser. But the main point is that I can use existing libraries to get a feed property, instead of having to scrape an HTML page. Cheers, -g From owner-atom-protocol Thu Sep 16 18:38:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1cYRe098055 for ; Thu, 16 Sep 2004 18:38:34 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H1cYN0098054 for atom-protocol-skb; Thu, 16 Sep 2004 18:38:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1cYip098045 for ; Thu, 16 Sep 2004 18:38:34 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 220DF47BF7 for ; Thu, 16 Sep 2004 18:37:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D1603F1-084A-11D9-BC18-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit From: Ezra Cooper Subject: Re: ProtocolDataModel issues Date: Thu, 16 Sep 2004 18:39:06 -0700 To: Atom Protocol X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I had understood that on this team we'd be talking about issues related to manipulating the server's objects, including objects that are not normally represented in a "feed" (list of entries). In order to do that we should set a scope: which objects do we want to be able to manipulate using Atom? Here's my proposal: * Entries * Authors (Users, Principals) * Feeds/Blogs/Channels/Streams/... * Categories * Templates A Category has properties: name, URI, and (optionally) a type. The type could identify a categorization system in which this category participates, if it's helpful to know that. A Template has properties: title, content, URI, MIME Type. The Feed resource (it's more like a Meal to me) has a "title" and URI and would provide the discoverability center for all the other things. If a client wants to know what categories can be applied to an entry, it can use the Feed resource to discover a list of allowable categories. Those things could be found under a GET or a PROPFIND or somehow else; I don't feel strongly about it. What goes in an Author? I don't know yet. Are there other objects that should be Atomized? Is this too many? Ezra From owner-atom-protocol Thu Sep 16 18:45:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1jx0D098487 for ; Thu, 16 Sep 2004 18:45:59 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H1jxDR098486 for atom-protocol-skb; Thu, 16 Sep 2004 18:45:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1jxJS098479 for ; Thu, 16 Sep 2004 18:45:59 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 31A0647BF7; Thu, 16 Sep 2004 18:44:53 -0700 (PDT) In-Reply-To: <20040917003559.GA8305@google.com> References: <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: Atom Protocol From: Ezra Cooper Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Date: Thu, 16 Sep 2004 18:46:33 -0700 To: Greg Stein X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (apologies if I've misrenamed the subject there) On Sep 16, 2004, at 5:35 PM, Greg Stein wrote: > Personally, I don't want to scrub thru HTML cruft to try and find a > feed. > I want to PROPFIND it. The response for PROPFIND is well-defined and > very > well-formed XML. I also have tools to easily do that, unlike trying to > extract some element from a page. Greg, are you saying you want to PROPFIND the URL of the site itself, such as http://diveintomark.org/ ? As opposed to doing a GET on that and finding the master introspection URL within the resulting HTML? If so, I'm opposed. Many sites (those of the proverbial Bob) will be serving static HTML at that location and won't have the luxury of responding to a PROPFIND there. If you're saying you want to do a PROPFIND at a *different* URL, then I'm fine with it. But what's the advantage of doing a PROPFIND as opposed to just a GET at that URL? Ezra From owner-atom-protocol Thu Sep 16 18:47:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1lpv9098544 for ; Thu, 16 Sep 2004 18:47:51 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H1lpgP098543 for atom-protocol-skb; Thu, 16 Sep 2004 18:47:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H1lpG8098533 for ; Thu, 16 Sep 2004 18:47:51 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 8799E47BF7 for ; Thu, 16 Sep 2004 18:46:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-protocol@imc.org From: Ezra Cooper Subject: Digest Auth in Atom Date: Thu, 16 Sep 2004 18:48:26 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As we've discussed a little bit in the past, some of the benefits of HTTP Digest authentication are: (1) Passwords need not be stored in the clear (2) Server chooses nonces and can determine how long it wants to keep them around (3) No problems with maladjusted clocks (4) Reasonably well-known and widely implemented These reasons, in particular number (1), make it very attractive for tools running in shared hosting environments, and we at Six Apart favor HTTP Digest over WSSE for becoming a part of the Atom spec. Is anyone else interested in working on this? I've got a working (at least, limping) implementation of HTTP Digest authentication within Movable Type's Atom implementation. Aside from using X-Atom-Authorization as the request header, I think it conforms to the spec. Ezra From owner-atom-protocol Thu Sep 16 19:17:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H2HqK2099981 for ; Thu, 16 Sep 2004 19:17:52 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H2Hq27099980 for atom-protocol-skb; Thu, 16 Sep 2004 19:17:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H2Hq4O099972 for ; Thu, 16 Sep 2004 19:17:52 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8H2HqXg001622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 19:17:52 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C88Js-0002aq-P5 by authid ; Thu, 16 Sep 2004 19:17:52 -0700 Date: Thu, 16 Sep 2004 19:17:52 -0700 From: Greg Stein To: Ezra Cooper Cc: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Message-ID: <20040917021752.GE8305@google.com> References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 16, 2004 at 06:46:33PM -0700, Ezra Cooper wrote: > (apologies if I've misrenamed the subject there) Well, the real subject is "let's talk some protocol for this piece of data" :-) > On Sep 16, 2004, at 5:35 PM, Greg Stein wrote: > > >Personally, I don't want to scrub thru HTML cruft to try and find a > >feed. > >I want to PROPFIND it. The response for PROPFIND is well-defined and > >very > >well-formed XML. I also have tools to easily do that, unlike trying to > >extract some element from a page. > > Greg, are you saying you want to PROPFIND the URL of the site itself, > such as http://diveintomark.org/ ? As opposed to doing a GET on that > and finding the master introspection URL within the resulting HTML? Yes. > If so, I'm opposed. Many sites (those of the proverbial Bob) will be > serving static HTML at that location and won't have the luxury of > responding to a PROPFIND there. I understand. I'm interested in moving things forward rather than staying mired in a world of sub-par servers. But that's just me :-) And I also know it is a controversial part of protocol design. It is just as fundamental as the "should we use SOAP? or just POST? or a REST model?" And because we could get mired in that conversation, I hoped to avoid it for now and simply elaborate on the data items. [ and discussion like this is good: it reinforces that our data model has got the needed bits. in this case, I'm talking about a PROPFIND to fetch the list of pairs which are listed on the ProtocolDataModel wiki page. my client could then peruse the list of feeds to find the Atom 1.0 feed. ] > If you're saying you want to do a PROPFIND at a *different* URL, then > I'm fine with it. But what's the advantage of doing a PROPFIND as > opposed to just a GET at that URL? Why one URL over another? If the home page can't do a PROPFIND, then I doubt any other can. And even if you *did* use a different URL, what would that be? How would I derive it, given the home page URL. Re: advantages: already stated. I'd much rather use a WebDAV library to do a PROPFIND and get my answer, than having to scrape an HTML page. The former is deterministic, and I feel the latter is not entirely so because of the vagaries of crappy HTML out there. Cheers, -g From owner-atom-protocol Thu Sep 16 20:09:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H39qaF003581 for ; Thu, 16 Sep 2004 20:09:52 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H39q7j003580 for atom-protocol-skb; Thu, 16 Sep 2004 20:09:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H39po6003573 for ; Thu, 16 Sep 2004 20:09:52 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so335875rnl for ; Thu, 16 Sep 2004 20:09:58 -0700 (PDT) Received: by 10.38.81.59 with SMTP id e59mr362466rnb; Thu, 16 Sep 2004 20:09:58 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Thu, 16 Sep 2004 20:09:58 -0700 (PDT) Message-ID: <14be96d3040916200916e734fe@mail.gmail.com> Date: Thu, 16 Sep 2004 23:09:58 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: ProtocolDataModel issues Cc: atom-protocol@imc.org In-Reply-To: <20040917012513.GC8305@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> <20040917012513.GC8305@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 18:25:13 -0700, Greg Stein wrote: > But the main point is that I can use existing libraries to get a feed > property, instead of having to scrape an HTML page. You can use "existing libraries" to get an autodiscovery link too: http://diveintomark.org/tests/client/autodiscovery/ http://diveintomark.org/tests/client/autodiscovery/atomautodiscovery.py But that's not the point. The point is that we have a feed autodiscovery spec already. If you want to suggest changes to it, write a Pace and we can discuss the relative merits of your proposal. It's difficult to discuss the merits of "HTML is hard." -- Cheers, -Mark From owner-atom-protocol Thu Sep 16 20:35:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3ZfYD005914 for ; Thu, 16 Sep 2004 20:35:41 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H3ZfRN005912 for atom-protocol-skb; Thu, 16 Sep 2004 20:35:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3Zf7b005886 for ; Thu, 16 Sep 2004 20:35:41 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8H3ZgYR025185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Sep 2004 20:35:42 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C89XC-0004Ii-6v by authid for ; Thu, 16 Sep 2004 20:35:42 -0700 Date: Thu, 16 Sep 2004 20:35:42 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: feed property (was: ProtocolDataModel issues) Message-ID: <20040917033542.GI8305@google.com> References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> <20040917012513.GC8305@google.com> <14be96d3040916200916e734fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14be96d3040916200916e734fe@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 16, 2004 at 11:09:58PM -0400, Mark Pilgrim wrote: > On Thu, 16 Sep 2004 18:25:13 -0700, Greg Stein wrote: > > But the main point is that I can use existing libraries to get a feed > > property, instead of having to scrape an HTML page. > > You can use "existing libraries" to get an autodiscovery link too: > http://diveintomark.org/tests/client/autodiscovery/ > http://diveintomark.org/tests/client/autodiscovery/atomautodiscovery.py That's one library. Got one for Java? C? PHP? Perl? > But that's not the point. Agreed :-) It's really about using existing mechanism, rather than coming up with new stuff. > The point is that we have a feed > autodiscovery spec already. If you want to suggest changes to it, > write a Pace and we can discuss the relative merits of your proposal. > It's difficult to discuss the merits of "HTML is hard." My proposal is something very simple: Every resource in a blog (or wiki, or whatever) contains a WebDAV property that specifies the feed for that blog. The property has the following schema: (where href is defined in RFC 2518, Section 12.3) (the XML namespace for this element is TBD) That's it. Not a whole internet draft, but a single property fitting into the already-defined scope of WebDAV properties. Cheers, -g From owner-atom-protocol Thu Sep 16 20:27:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3RrCf005148 for ; Thu, 16 Sep 2004 20:27:53 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H3Rr1a005147 for atom-protocol-skb; Thu, 16 Sep 2004 20:27:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3Rqgg005140 for ; Thu, 16 Sep 2004 20:27:52 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i8H3ShE9022808; Thu, 16 Sep 2004 23:28:44 -0400 Message-ID: <414A59BA.3030907@intertwingly.net> Date: Thu, 16 Sep 2004 23:27:54 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: atom-protocol@imc.org Subject: Re: Digest Auth in Atom References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > As we've discussed a little bit in the past, some of the benefits of > HTTP Digest authentication are: > > (1) Passwords need not be stored in the clear > (2) Server chooses nonces and can determine how long it wants to keep > them around > (3) No problems with maladjusted clocks > (4) Reasonably well-known and widely implemented > > These reasons, in particular number (1), make it very attractive for > tools running in shared hosting environments, and we at Six Apart favor > HTTP Digest over WSSE for becoming a part of the Atom spec. > > Is anyone else interested in working on this? I've got a working (at > least, limping) implementation of HTTP Digest authentication within > Movable Type's Atom implementation. Aside from using > X-Atom-Authorization as the request header, I think it conforms to the > spec. By #1, are you saying that things work out if you happen to have had the foresight to store passwords on the server with the scheme defined by digest authentication, or are you saying something more than that? #2 opens a potential for DOS attacks by non-authenticated users. This may be an acceptable risk. #4's wide implementation is somewhat reduced by use of the non-standard header. - - - There is an aspect of challenge/response that should be discussed. An HTTP GET request is relatively short, so a challenge is fairly inexpensive. This is not as true for POST. Consider a cell phone uploading a picture. This can be mitigated by careful use of a nextnonce, something which requires careful design, library support, and single threading. - - - We probably should consider what happens if md5 is cracked. - - - None of the above points are fatal. All in all, I believe that we will find that: (1) We can't standardize on a single authentication method. Some environments will require Kerberos, for example. (2) Point #4 above (security algorithm known to the IETF), is actually stronger than you give it credit. - Sam Ruby From owner-atom-protocol Thu Sep 16 20:38:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3c1PV006161 for ; Thu, 16 Sep 2004 20:38:01 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H3c1i7006160 for atom-protocol-skb; Thu, 16 Sep 2004 20:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8H3c0iZ006154 for ; Thu, 16 Sep 2004 20:38:00 -0700 (PDT) (envelope-from rooneg@electricjellyfish.net) Received: (qmail 49706 invoked from network); 17 Sep 2004 03:38:04 -0000 Received: from ool-182c4fa2.dyn.optonline.net (HELO ?192.168.0.2?) (24.44.79.162) by relay.pair.com with SMTP; 17 Sep 2004 03:38:04 -0000 X-pair-Authenticated: 24.44.79.162 Message-ID: <414A5C34.3070106@electricjellyfish.net> Date: Thu, 16 Sep 2004 23:38:28 -0400 From: Garrett Rooney User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: atom-protocol@imc.org Subject: Re: feed property References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> <20040917012513.GC8305@google.com> <14be96d3040916200916e734fe@mail.gmail.com> <20040917033542.GI8305@google.com> In-Reply-To: <20040917033542.GI8305@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > My proposal is something very simple: > > Every resource in a blog (or wiki, or whatever) contains a WebDAV > property that specifies the feed for that blog. The property has the > following schema: > > > > (where href is defined in RFC 2518, Section 12.3) > > (the XML namespace for this element is TBD) > > That's it. Not a whole internet draft, but a single property fitting into > the already-defined scope of WebDAV properties. What if there are multiple feeds associated with a page? -garrett From owner-atom-protocol Thu Sep 16 20:43:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3hJC9006435 for ; Thu, 16 Sep 2004 20:43:19 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H3hJfa006434 for atom-protocol-skb; Thu, 16 Sep 2004 20:43:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3hICg006417 for ; Thu, 16 Sep 2004 20:43:18 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8H3hF6d020273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Sep 2004 20:43:15 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C89eV-0004J8-B9 by authid for ; Thu, 16 Sep 2004 20:43:15 -0700 Date: Thu, 16 Sep 2004 20:43:15 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Re: Digest Auth in Atom Message-ID: <20040917034315.GA3456@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think the Atom protocol spec should simply state that a secure authentication scheme MUST be used (e.g. no Basic unless SSL/TLS is used to encrypt the channel). Take a look at RFC 2518, Section 17.1 as an example of how we might want to talk about authentication. I'm not sure that I like the "MUST support Digest" (many DAV implementors have ignored that part, so it is demonstrable that saying it doesn't make it happen). Also note that it is simply a section in the standard "Security Considerations" section of an IETF spec. fwiw, Blogger will be supporting Basic over SSL as the "standard" mechanism for interacting with Atom resources. Cheers, -g On Thu, Sep 16, 2004 at 06:48:26PM -0700, Ezra Cooper wrote: > > As we've discussed a little bit in the past, some of the benefits of > HTTP Digest authentication are: > > (1) Passwords need not be stored in the clear > (2) Server chooses nonces and can determine how long it wants to keep > them around > (3) No problems with maladjusted clocks > (4) Reasonably well-known and widely implemented > > These reasons, in particular number (1), make it very attractive for > tools running in shared hosting environments, and we at Six Apart favor > HTTP Digest over WSSE for becoming a part of the Atom spec. > > Is anyone else interested in working on this? I've got a working (at > least, limping) implementation of HTTP Digest authentication within > Movable Type's Atom implementation. Aside from using > X-Atom-Authorization as the request header, I think it conforms to the > spec. > > Ezra > From owner-atom-protocol Thu Sep 16 20:47:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3llLr006729 for ; Thu, 16 Sep 2004 20:47:47 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H3lli8006728 for atom-protocol-skb; Thu, 16 Sep 2004 20:47:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H3llEs006718 for ; Thu, 16 Sep 2004 20:47:47 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8H3leEo028172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 20:47:41 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C89im-0004Mp-UX by authid ; Thu, 16 Sep 2004 20:47:40 -0700 Date: Thu, 16 Sep 2004 20:47:40 -0700 From: Greg Stein To: Garrett Rooney Cc: atom-protocol@imc.org Subject: Re: feed property Message-ID: <20040917034740.GB3456@google.com> References: <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> <20040917012513.GC8305@google.com> <14be96d3040916200916e734fe@mail.gmail.com> <20040917033542.GI8305@google.com> <414A5C34.3070106@electricjellyfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414A5C34.3070106@electricjellyfish.net> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 16, 2004 at 11:38:28PM -0400, Garrett Rooney wrote: > Greg Stein wrote: > >My proposal is something very simple: > > > > Every resource in a blog (or wiki, or whatever) contains a WebDAV > > property that specifies the feed for that blog. The property has the > > following schema: > > > > > > > > (where href is defined in RFC 2518, Section 12.3) > > > > (the XML namespace for this element is TBD) > > > >That's it. Not a whole internet draft, but a single property fitting into > >the already-defined scope of WebDAV properties. > > What if there are multiple feeds associated with a page? Heh. Shoulda paid attention to the data model in the ProtocolDataModel wiki page :-) It defined things as a list of pairs. This might be one possibility: An example would be: http://something/atom/1.0 http://example.com/blog/atom.xml http://something/rss/0.9 http://example.com/blog/rss.xml Cheers, -g From owner-atom-protocol Thu Sep 16 21:33:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H4XRvf009930 for ; Thu, 16 Sep 2004 21:33:27 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H4XR96009929 for atom-protocol-skb; Thu, 16 Sep 2004 21:33:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H4XQpg009900 for ; Thu, 16 Sep 2004 21:33:26 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so291050rnk for ; Thu, 16 Sep 2004 21:33:28 -0700 (PDT) Received: by 10.38.125.33 with SMTP id x33mr1884354rnc; Thu, 16 Sep 2004 21:33:28 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Thu, 16 Sep 2004 21:33:28 -0700 (PDT) Message-ID: <14be96d304091621331846037d@mail.gmail.com> Date: Fri, 17 Sep 2004 00:33:28 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: feed property (was: ProtocolDataModel issues) Cc: atom-protocol@imc.org In-Reply-To: <20040917033542.GI8305@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> <20040917012513.GC8305@google.com> <14be96d3040916200916e734fe@mail.gmail.com> <20040917033542.GI8305@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 20:35:42 -0700, Greg Stein wrote: > > On Thu, Sep 16, 2004 at 11:09:58PM -0400, Mark Pilgrim wrote: > > On Thu, 16 Sep 2004 18:25:13 -0700, Greg Stein wrote: > > > But the main point is that I can use existing libraries to get a feed > > > property, instead of having to scrape an HTML page. > > > > You can use "existing libraries" to get an autodiscovery link too: > > http://diveintomark.org/tests/client/autodiscovery/ > > http://diveintomark.org/tests/client/autodiscovery/atomautodiscovery.py > > That's one library. Got one for Java? C? PHP? Perl? Perl: http://search.cpan.org/~btrott/Feed-Find-0.03/lib/Feed/Find.pm PHP: http://keithdevens.com/weblog/archive/2002/Jun/03/RSSAuto-DiscoveryPHP C#: http://sourceforge.net/project/showfiles.php?group_id=96589&package_id=103276 Shall I go on? It's embarrassingly easy to find information these days; you can thank your employer for that. > My proposal is something very simple: > > Every resource in a blog (or wiki, or whatever) contains a WebDAV > property that specifies the feed for that blog. The property has the > following schema: > > > > (where href is defined in RFC 2518, Section 12.3) > > (the XML namespace for this element is TBD) > > That's it. Not a whole internet draft, but a single property fitting into > the already-defined scope of WebDAV properties. Thank you. What are the impacts on producers? Can individuals in a shared Apache hosting environment configure this for themselves, or do they need their sysadmin to install additional modules for them? How do you implement it under IIS? What are the impacts on consumers? Do existing HTTP libraries have a PROPFIND method, or do they have methods that are generic enough that a PROPFIND request could be built from scratch? Is this meant to completely replace the existing autodiscovery mechanism? If not, how do they interact? Does one override the other, and if so, which one takes precedence? Or are they cumulative, where if both are present then the page is presumed to have two associated feeds? Can this proposed mechanism work with different media types? The current autodiscovery mechanism gives the publisher the opportunity to provide a hint of the media type that a consumer would get if they dereferenced the feed URI. (Obviously once the URI is dereferenced, its actual media type takes precedence.) But this leaves the door open for extending the algorithm for other syndication formats (this is already used with RSS, though there is no ratified spec for it). It could also theoretically be used by Atom 2.0 if it had a different media type, or some successor to Atom. Can a publisher do this under your proposal? If not, why do you feel this is unnecessary? Can this proposed mechanism represent more than one feed associated with a page? Which one is considered the primary one? Is order significant, or are there additional properties? Can this proposed mechanism define a title for each autodiscovery URI? Current consumers use the title to distinguish between multiple feeds, in the case where a page has multiple autodiscovery links. Can a publisher do this under your proposal? If not, why do you feel this is unnecessary? Can the href be relative? If so, what is it relative to? RFC 2518 defines the datatype of href as a URI, with a normative reference to RFC 2068. But RFC 2068 was obsoleted by RFC 2616, which defines URIs by reference to RFC 2396, which does not define the meaning (or more to the point, the character encoding) of the percent-encoded characters %80 through %FF. (HTML, on the other hand, specifically defines this in Appendix B.2.1.) How do you intend to handle i18n issues in URIs? Do you have plans to build a test suite to accompany your proposed autodiscovery mechanism? -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 06:45:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDjsru068560 for ; Fri, 17 Sep 2004 06:45:54 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HDjsIb068559 for atom-protocol-skb; Fri, 17 Sep 2004 06:45:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HDjrIo068549 for ; Fri, 17 Sep 2004 06:45:54 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C8J3c-0001rT-7L; Fri, 17 Sep 2004 13:45:48 +0000 Message-ID: <414AEA9A.5010505@franklinmint.fm> Date: Fri, 17 Sep 2004 09:46:02 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: Ezra Cooper , Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> In-Reply-To: <20040917021752.GE8305@google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > On Thu, Sep 16, 2004 at 06:46:33PM -0700, Ezra Cooper wrote: > >>Greg, are you saying you want to PROPFIND the URL of the site itself, >>such as http://diveintomark.org/ ? As opposed to doing a GET on that >>and finding the master introspection URL within the resulting HTML? > > > Yes. > > >>If so, I'm opposed. Many sites (those of the proverbial Bob) will be >>serving static HTML at that location and won't have the luxury of >>responding to a PROPFIND there. > > > I understand. I'm interested in moving things forward rather than staying > mired in a world of sub-par servers. > > But that's just me :-) I doubt we'll reach consensus to abandon HTML autodiscovery. It works and seems to be useful for a rather popular class of application called web browsers[0,1]. Robert Sayre [0] http://www.mozilla.org/products/firefox/live-bookmarks.html [1] http://www.apple.com/macosx/tiger/safari.html From owner-atom-protocol Fri Sep 17 07:10:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HEAVjr070929 for ; Fri, 17 Sep 2004 07:10:31 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HEAVIn070928 for atom-protocol-skb; Fri, 17 Sep 2004 07:10:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HEAUQ8070921 for ; Fri, 17 Sep 2004 07:10:31 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so358635rnk for ; Fri, 17 Sep 2004 07:10:24 -0700 (PDT) Received: by 10.38.92.63 with SMTP id p63mr43123rnb; Fri, 17 Sep 2004 07:10:15 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 07:10:15 -0700 (PDT) Message-ID: <14be96d3040917071079464e59@mail.gmail.com> Date: Fri, 17 Sep 2004 10:10:15 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: Ezra Cooper , Atom Protocol In-Reply-To: <20040917021752.GE8305@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 19:17:52 -0700, Greg Stein wrote: > On Thu, Sep 16, 2004 at 06:46:33PM -0700, Ezra Cooper wrote: > > Greg, are you saying you want to PROPFIND the URL of the site itself, > > such as http://diveintomark.org/ ? As opposed to doing a GET on that > > and finding the master introspection URL within the resulting HTML? > > Yes. > > > If so, I'm opposed. Many sites (those of the proverbial Bob) will be > > serving static HTML at that location and won't have the luxury of > > responding to a PROPFIND there. > > I understand. I'm interested in moving things forward rather than staying > mired in a world of sub-par servers. In other words, you are proposing a mechanism that will leave millions of your own customers out in the cold. Words fail me. > Re: advantages: already stated. I'd much rather use a WebDAV library to do > a PROPFIND and get my answer, than having to scrape an HTML page. The > former is deterministic, and I feel the latter is not entirely so because > of the vagaries of crappy HTML out there. I was under the impression that HTML was a completely deterministic SGML application and could be validated with off-the-shelf SGML tools. Could you give an example of non-deterministic HTML? -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 11:09:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HI9JFY090534 for ; Fri, 17 Sep 2004 11:09:19 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HI9JCq090533 for atom-protocol-skb; Fri, 17 Sep 2004 11:09:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HI9IKD090519 for ; Fri, 17 Sep 2004 11:09:18 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 81EA147BF7; Fri, 17 Sep 2004 11:08:05 -0700 (PDT) In-Reply-To: <20040917021752.GE8305@google.com> References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Protocol From: Ezra Cooper Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Date: Fri, 17 Sep 2004 11:09:49 -0700 To: Greg Stein X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 16, 2004, at 7:17 PM, Greg Stein wrote: >> If you're saying you want to do a PROPFIND at a *different* URL, then >> I'm fine with it. But what's the advantage of doing a PROPFIND as >> opposed to just a GET at that URL? > > Why one URL over another? If the home page can't do a PROPFIND, then I > doubt any other can. And even if you *did* use a different URL, what > would > that be? How would I derive it, given the home page URL. Many systems partition their URLs into those which return a static page and those which invoke some code to respond to that URL. It's easy to respond to PROPFIND at, say, /cgi-bin/something-or-other but it's impossible to respond to it at /index.html because the webserver will serve the file from disk no matter the request method. This is a very standard and widely-deployed configuration, and configuring it to treat the PROPFIND specially would be beyond the abilities of many hosting providers, let alone the users who would need this feature in order to be Atom-compliant. Please note, it's not the use of non-GET request methods that I'm opposed to: it's the requirement of varying the response based on request method *at a URL that would otherwise be a static HTML page.* If we have the privilege of determining an alternate URL for this information, the request method is not important. > I understand. I'm interested in moving things forward rather than > staying > mired in a world of sub-par servers. I think what we're talking about is a pretty large class of "par" servers--that is, average ones. If I could redesign the common webservers and change the policies of the majority of web hosting providers, there are a lot of things I would change. However, I think that task is "out of scope" for the atompub WG. To the extent that we're establishing a "standard" here, let's select a solution that works for everybody, even if it's inconvenient for some. Ezra From owner-atom-protocol Fri Sep 17 11:40:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HIeCAm092953 for ; Fri, 17 Sep 2004 11:40:12 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HIeCws092952 for atom-protocol-skb; Fri, 17 Sep 2004 11:40:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HIeBb7092941 for ; Fri, 17 Sep 2004 11:40:12 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so437672rnb for ; Fri, 17 Sep 2004 11:40:07 -0700 (PDT) Received: by 10.38.8.29 with SMTP id 29mr248050rnh; Fri, 17 Sep 2004 11:39:49 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Fri, 17 Sep 2004 11:39:49 -0700 (PDT) Message-ID: <1f2ed5cd04091711392fd8f0db@mail.gmail.com> Date: Fri, 17 Sep 2004 20:39:49 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Ezra Cooper Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: Greg Stein , Atom Protocol In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg, one question: how does a client obtain the URI at which to apply the PROPFIND? Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Fri Sep 17 13:34:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKYUY9003727 for ; Fri, 17 Sep 2004 13:34:30 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKYUqO003726 for atom-protocol-skb; Fri, 17 Sep 2004 13:34:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKYUwJ003717 for ; Fri, 17 Sep 2004 13:34:30 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8HKYPmk019420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2004 13:34:25 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8PR3-0003fl-9M by authid ; Fri, 17 Sep 2004 13:34:25 -0700 Date: Fri, 17 Sep 2004 13:34:25 -0700 From: Greg Stein To: Danny Ayers Cc: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Message-ID: <20040917203425.GC13054@google.com> References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2ed5cd04091711392fd8f0db@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 08:39:49PM +0200, Danny Ayers wrote: > Greg, one question: how does a client obtain the URI at which to apply > the PROPFIND? I'm saying that you just PROPFIND on any page of the blog, and you get back relevant information. Ezra was suggesting the user of an alternate URI, and I already asked "how do you get that URI?" I've got no idea, and I don't think that model works as well. When I'm looking at a blog page (say http://www.evhead.com/), then I want to just PROPFIND that to get the feed information, the pointer to the principal involved ("author"), links to archives, and a blogroll. All of that could be returned by a PROPFIND from that blog home page. I'm not entirely sure which properties go with what resources, but I think the concept is robust: just ask the resource you're looking at for the information you need, or pointers to additional info. Cheers, -g From owner-atom-protocol Fri Sep 17 13:39:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKd1s5004283 for ; Fri, 17 Sep 2004 13:39:01 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKd1Ul004282 for atom-protocol-skb; Fri, 17 Sep 2004 13:39:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8HKd0kr004264 for ; Fri, 17 Sep 2004 13:39:00 -0700 (PDT) (envelope-from rooneg@electricjellyfish.net) Received: (qmail 53846 invoked from network); 17 Sep 2004 20:39:01 -0000 Received: from inetuser.factset.com (HELO ?164.55.144.110?) (164.55.254.103) by relay.pair.com with SMTP; 17 Sep 2004 20:39:01 -0000 X-pair-Authenticated: 164.55.254.103 Message-ID: <414B4B66.5050203@electricjellyfish.net> Date: Fri, 17 Sep 2004 16:39:02 -0400 From: Garrett Rooney User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: Danny Ayers , Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> In-Reply-To: <20040917203425.GC13054@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > I'm saying that you just PROPFIND on any page of the blog, and you get > back relevant information. Ezra was suggesting the user of an alternate > URI, and I already asked "how do you get that URI?" I've got no idea, and > I don't think that model works as well. > > When I'm looking at a blog page (say http://www.evhead.com/), then I want > to just PROPFIND that to get the feed information, the pointer to the > principal involved ("author"), links to archives, and a blogroll. All of > that could be returned by a PROPFIND from that blog home page. > > I'm not entirely sure which properties go with what resources, but I think > the concept is robust: just ask the resource you're looking at for the > information you need, or pointers to additional info. It may be robust, but it assumes a reasonably smart server. Many people here seem to consider it a design goal that the Atom API function in the absence of such a server, on a shared hosting service with only simple CGI access. In this kind of situation we are a bit more limited. Since this seems like a fairly fundamental difference of opinion, perhaps it should be resolved first. What are the requirements we're willing to impose on implementors of the Atom API? -garrett From owner-atom-protocol Fri Sep 17 13:50:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKomH8005952 for ; Fri, 17 Sep 2004 13:50:48 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKomWH005951 for atom-protocol-skb; Fri, 17 Sep 2004 13:50:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKom1b005937 for ; Fri, 17 Sep 2004 13:50:48 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 016F647BF8; Fri, 17 Sep 2004 13:49:37 -0700 (PDT) In-Reply-To: <20040917203425.GC13054@google.com> References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54801214-08EB-11D9-8753-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: Atom Protocol , Danny Ayers From: Ezra Cooper Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Date: Fri, 17 Sep 2004 13:51:21 -0700 To: Greg Stein X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 17, 2004, at 1:34 PM, Greg Stein wrote: > On Fri, Sep 17, 2004 at 08:39:49PM +0200, Danny Ayers wrote: >> Greg, one question: how does a client obtain the URI at which to apply >> the PROPFIND? > > I'm saying that you just PROPFIND on any page of the blog, and you get > back relevant information. Ezra was suggesting the user of an alternate > URI, and I already asked "how do you get that URI?" I've got no idea, > and I thought this was pretty well understood. We just put a tag in the HTML at http://www.evhead.com/. The advantage of this approach is that it works for every producer, regardless of whether they use static or dynamic pages. Ezra From owner-atom-protocol Fri Sep 17 13:50:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKotRF005964 for ; Fri, 17 Sep 2004 13:50:56 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKotPW005963 for atom-protocol-skb; Fri, 17 Sep 2004 13:50:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKotrq005957 for ; Fri, 17 Sep 2004 13:50:55 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so173277rnl for ; Fri, 17 Sep 2004 13:50:59 -0700 (PDT) Received: by 10.38.88.16 with SMTP id l16mr205723rnb; Fri, 17 Sep 2004 13:50:58 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 13:50:58 -0700 (PDT) Message-ID: <14be96d3040917135032e22b59@mail.gmail.com> Date: Fri, 17 Sep 2004 16:50:58 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: Atom Protocol In-Reply-To: <20040917203425.GC13054@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504091511101115c5df@mail.gmail.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 13:34:25 -0700, Greg Stein wrote: > When I'm looking at a blog page (say http://www.evhead.com/), then I want > to just PROPFIND that to get the feed information, the pointer to the > principal involved ("author"), links to archives, and a blogroll. All of > that could be returned by a PROPFIND from that blog home page. All of that could also be returned in well-defined elements within the HTML document. In fact, that's what everyone is already doing today, and it is widely supported in both general-purpose browsers and single-purpose aggregators. It also has the advantage of working for millions of your own customers, which PROPFIND would not. > I'm not entirely sure which properties go with what resources, but I think > the concept is robust: just ask the resource you're looking at for the > information you need, or pointers to additional info. As stated, the "concept" is abstract enough to be meaningless. If you have a concrete proposal, please write up a Pace so that we can discuss it. For those unfamiliar with the process, a Pace is intended to contain camera-ready copy, ready to be copied and pasted into a specification. If it is a modification to an existing specification, you need to clearly state which sections and paragraphs are being modified. Your Pace should also address all of the questions listed here: http://www.imc.org/atom-protocol/mail-archive/msg00065.html -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 13:51:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKp2cD005981 for ; Fri, 17 Sep 2004 13:51:02 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKp2Cs005980 for atom-protocol-skb; Fri, 17 Sep 2004 13:51:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKp2AN005967 for ; Fri, 17 Sep 2004 13:51:02 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8HKowKZ002545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2004 13:50:58 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8Ph4-0003ku-HU by authid ; Fri, 17 Sep 2004 13:50:58 -0700 Date: Fri, 17 Sep 2004 13:50:58 -0700 From: Greg Stein To: Ezra Cooper Cc: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Message-ID: <20040917205058.GA14157@google.com> References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 11:09:49AM -0700, Ezra Cooper wrote: > On Sep 16, 2004, at 7:17 PM, Greg Stein wrote: > >>If you're saying you want to do a PROPFIND at a *different* URL, then > >>I'm fine with it. But what's the advantage of doing a PROPFIND as > >>opposed to just a GET at that URL? > > > >Why one URL over another? If the home page can't do a PROPFIND, then I > >doubt any other can. And even if you *did* use a different URL, what > >would > >that be? How would I derive it, given the home page URL. > > Many systems partition their URLs into those which return a static page > and those which invoke some code to respond to that URL. It's easy to > respond to PROPFIND at, say, /cgi-bin/something-or-other but it's > impossible to respond to it at /index.html because the webserver will > serve the file from disk no matter the request method. This is a very I'm not familiar with any web server that does that. Apache and IIS both examine the request method. Both servers support properties on static pages. Properties on dynamic pages are actually the more difficult part, since there is confusion between "who serves the GET and who serves the PROPFIND?" > standard and widely-deployed configuration, and configuring it to treat > the PROPFIND specially would be beyond the abilities of many hosting > providers, let alone the users who would need this feature in order to > be Atom-compliant. I'm not understanding the configuration scenario you're talking about. I've never seen a server that doesn't obey the method. I imagine it's possible to write a CGI script that ignores it. Is that what you're referring to? > Please note, it's not the use of non-GET request methods that I'm > opposed to: it's the requirement of varying the response based on > request method *at a URL that would otherwise be a static HTML page.* But that is what HTTP is all about. You change the request method to perform different operations. That is the fundamental basis of the REST architecture. > If we have the privilege of determining an alternate URL for this > information, the request method is not important. *blink* ... The request method is ALWAYS important. That's how HTTP works. >... Cheers, -g From owner-atom-protocol Fri Sep 17 13:55:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKtOwk006452 for ; Fri, 17 Sep 2004 13:55:24 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKtOmi006451 for atom-protocol-skb; Fri, 17 Sep 2004 13:55:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKtNgo006430 for ; Fri, 17 Sep 2004 13:55:23 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8HKtHAn018717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2004 13:55:17 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8PlF-0003lA-ED by authid ; Fri, 17 Sep 2004 13:55:17 -0700 Date: Fri, 17 Sep 2004 13:55:17 -0700 From: Greg Stein To: Mark Pilgrim Cc: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Message-ID: <20040917205517.GC3456@google.com> References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <14be96d3040917071079464e59@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14be96d3040917071079464e59@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 10:10:15AM -0400, Mark Pilgrim wrote: > On Thu, 16 Sep 2004 19:17:52 -0700, Greg Stein wrote: >... > > > If so, I'm opposed. Many sites (those of the proverbial Bob) will be > > > serving static HTML at that location and won't have the luxury of > > > responding to a PROPFIND there. > > > > I understand. I'm interested in moving things forward rather than staying > > mired in a world of sub-par servers. > > In other words, you are proposing a mechanism that will leave millions > of your own customers out in the cold. Eh? How does that follow? blogspot.com can easily support a PROPFIND if that is how this stuff pans out. >... > > Re: advantages: already stated. I'd much rather use a WebDAV library to do > > a PROPFIND and get my answer, than having to scrape an HTML page. The > > former is deterministic, and I feel the latter is not entirely so because > > of the vagaries of crappy HTML out there. > > I was under the impression that HTML was a completely deterministic > SGML application and could be validated with off-the-shelf SGML tools. > Could you give an example of non-deterministic HTML? Blogger users can manipulate their HTML template in bad bad ways. We cannot always insert a element into the thing. We have enough troubles with just the navbar. But PROPFIND? I can guarantee that is always served properly. Cheers, -g From owner-atom-protocol Fri Sep 17 13:55:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKtJ4H006438 for ; Fri, 17 Sep 2004 13:55:19 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HKtJSd006437 for atom-protocol-skb; Fri, 17 Sep 2004 13:55:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HKtJNF006429 for ; Fri, 17 Sep 2004 13:55:19 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C8PlE-0001Y4-Bs; Fri, 17 Sep 2004 20:55:16 +0000 Message-ID: <414B4F42.3050605@franklinmint.fm> Date: Fri, 17 Sep 2004 16:55:30 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garrett Rooney CC: Greg Stein , Danny Ayers , Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <414B4B66.5050203@electricjellyfish.net> In-Reply-To: <414B4B66.5050203@electricjellyfish.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Garrett Rooney wrote: > > It may be robust, but it assumes a reasonably smart server. Many people > here seem to consider it a design goal that the Atom API function in the > absence of such a server, on a shared hosting service with only simple > CGI access. In this kind of situation we are a bit more limited. > > Since this seems like a fairly fundamental difference of opinion, > perhaps it should be resolved first. What are the requirements we're > willing to impose on implementors of the Atom API? In case anyone is unfamiliar with "Bob", here's the text: "Let's talk about Bob. Bob has a weblog. Bob hosts his weblog on a low-end web hosting service, one which hosts several hundred weblogs on a single machine (a single IP address). Bob can FTP files to his web directory, and he can run CGI scripts in Perl and Python. But Bob has no remote shell access on his server (that costs extra), no .htaccess rights to change his Apache configuration (his hosting provider set AllowOverride None), no PHP scripts, and no database. He can serve static HTML files and run CGI scripts, and that's it. This is not a contrived scenario. Many web hosting providers offer exactly this environment, and two popular weblog publishing systems, Movable Type and Blosxom, run as CGI scripts in this environment. There are thousands of real people like Bob."[0] That's the been the baseline for server capabilities for some time now. Any change there would constitute a big shift in consensus. I don't consider PROPFIND on "index.html" to be a compelling enough feature to increase requirements for server implementations. That doesn't mean I'm against defining Atom-specific properties for a PROPFIND. Robert Sayre [0] http://www.xml.com/pub/a/2003/12/17/dive.html From owner-atom-protocol Fri Sep 17 14:00:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HL0w4e006870 for ; Fri, 17 Sep 2004 14:00:58 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HL0wdN006869 for atom-protocol-skb; Fri, 17 Sep 2004 14:00:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HL0vNU006859 for ; Fri, 17 Sep 2004 14:00:58 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so178899rnl for ; Fri, 17 Sep 2004 14:00:59 -0700 (PDT) Received: by 10.38.181.75 with SMTP id d75mr232193rnf; Fri, 17 Sep 2004 14:00:59 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 14:00:58 -0700 (PDT) Message-ID: <14be96d304091714004640c020@mail.gmail.com> Date: Fri, 17 Sep 2004 17:00:58 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: Atom Protocol In-Reply-To: <20040917205517.GC3456@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <14be96d3040917071079464e59@mail.gmail.com> <20040917205517.GC3456@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 13:55:17 -0700, Greg Stein wrote: > On Fri, Sep 17, 2004 at 10:10:15AM -0400, Mark Pilgrim wrote: > > On Thu, 16 Sep 2004 19:17:52 -0700, Greg Stein wrote: > >... > > > > If so, I'm opposed. Many sites (those of the proverbial Bob) will be > > > > serving static HTML at that location and won't have the luxury of > > > > responding to a PROPFIND there. > > > > > > I understand. I'm interested in moving things forward rather than staying > > > mired in a world of sub-par servers. > > > > In other words, you are proposing a mechanism that will leave millions > > of your own customers out in the cold. > > Eh? How does that follow? blogspot.com can easily support a PROPFIND if > that is how this stuff pans out. The last time I checked, Blogger worked by FTPing files to a remote server of my choice. -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 14:00:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HL0UjX006829 for ; Fri, 17 Sep 2004 14:00:30 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HL0UKJ006828 for atom-protocol-skb; Fri, 17 Sep 2004 14:00:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HL0UBv006811 for ; Fri, 17 Sep 2004 14:00:30 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8HL0NGo020635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2004 14:00:24 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8PqB-0003nE-Pu by authid ; Fri, 17 Sep 2004 14:00:23 -0700 Date: Fri, 17 Sep 2004 14:00:23 -0700 From: Greg Stein To: Garrett Rooney Cc: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Message-ID: <20040917210023.GD3456@google.com> References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <414B4B66.5050203@electricjellyfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414B4B66.5050203@electricjellyfish.net> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 04:39:02PM -0400, Garrett Rooney wrote: >... > It may be robust, but it assumes a reasonably smart server. Many people > here seem to consider it a design goal that the Atom API function in the > absence of such a server, on a shared hosting service with only simple > CGI access. In this kind of situation we are a bit more limited. Yah, and it kind of blows. Designing a protocol to accomodate the least common denominator may be useful in the short term, but I think it is suboptimal for the long term. When WebDAV was first spec'd out, nothing supported it. But today? Lots of support. In the long term, the protocol design meshes well with HTTP and the various bits of infrastructure. Take a look at your own work. "What? Feed optimization that requires server work? An Apache module? We can't rely on that. Let's do something that can be deployed by CGI scripts." That point of view would be very short-sighed. Your work has already filled in the server needs. Heck, a couple years from now, Apache might have native support for RFC 3229 with plugins to perform the various differencing options. > Since this seems like a fairly fundamental difference of opinion, > perhaps it should be resolved first. What are the requirements we're > willing to impose on implementors of the Atom API? I was hoping to defer the discussion, generate a data model, and then generate several protocol proposals around that model. One protocol could be HTTP/WebDAV/REST styled, one could be a SOAP binding, and one could be based (or whatever). Cheers, -g From owner-atom-protocol Fri Sep 17 14:08:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HL8ahV007521 for ; Fri, 17 Sep 2004 14:08:36 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HL8Zv0007520 for atom-protocol-skb; Fri, 17 Sep 2004 14:08:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HL8UPS007503 for ; Fri, 17 Sep 2004 14:08:30 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8HL8Y53014052 for ; Fri, 17 Sep 2004 15:08:34 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I47007XREQ92Z@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Fri, 17 Sep 2004 15:08:34 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I47003K2EQ912@mail.sun.net> for atom-protocol@imc.org; Fri, 17 Sep 2004 15:08:33 -0600 (MDT) Date: Fri, 17 Sep 2004 14:08:32 -0700 From: Tim Bray Subject: Re: Introspection (was Re: ProtocolDataModelIssues) In-reply-to: <414B4F42.3050605@franklinmint.fm> To: Robert Sayre Cc: Atom Protocol , Garrett Rooney , Greg Stein , Danny Ayers Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <414B4B66.5050203@electricjellyfish.net> <414B4F42.3050605@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 17, 2004, at 1:55 PM, Robert Sayre wrote: > I don't consider PROPFIND on "index.html" to be a compelling enough > feature to increase requirements for server implementations. That > doesn't mean I'm against defining Atom-specific properties for a > PROPFIND. Well-said. I'm not dogmatic on this one so I'm not going to lie across either fork of the road, but it seems to me that autodiscovery via HTML is is well-established and well-debugged and it would be silly for Atom to walk away from it. Having said that, Greg has made some good points and the PROPFIND in particular looks compelling. I can see nothing wrong with working out a proposal for "how you would accomplish some of all of the Atom Protocol goals using WebDAV capabilities". Then we could decide whether this is so clearly better than what we have now that we change horses, or whether we support the DAV approach as an option, or whether for some reason we just don't like it. But I don't see how we can do that without an actual proposal to look at. -Tim From owner-atom-protocol Fri Sep 17 14:10:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HLASd9007655 for ; Fri, 17 Sep 2004 14:10:28 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HLASYD007654 for atom-protocol-skb; Fri, 17 Sep 2004 14:10:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HLARfc007648 for ; Fri, 17 Sep 2004 14:10:27 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i8HLAVil004246 for ; Fri, 17 Sep 2004 15:10:31 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I47007CIETJKJ@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Fri, 17 Sep 2004 15:10:31 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I47002YZETIYM@mail.sun.net> for atom-protocol@imc.org; Fri, 17 Sep 2004 15:10:31 -0600 (MDT) Date: Fri, 17 Sep 2004 14:10:27 -0700 From: Tim Bray Subject: Re: Introspection (was Re: ProtocolDataModelIssues) In-reply-to: <20040917210023.GD3456@google.com> To: Greg Stein Cc: Atom Protocol , Garrett Rooney Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <414B4B66.5050203@electricjellyfish.net> <20040917210023.GD3456@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 17, 2004, at 2:00 PM, Greg Stein wrote: > I was hoping to defer the discussion, generate a data model, and then > generate several protocol proposals around that model. One protocol > could > be HTTP/WebDAV/REST styled, one could be a SOAP binding, and one could > be > based (or whatever). My feeling is that our data model is sufficiently well-understood (there are lots of implementations after all) that we could start looking at actual protocol proposals. I promise to look at them seriously when they arrive. -Tim From owner-atom-protocol Fri Sep 17 14:21:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HLLmSC008595 for ; Fri, 17 Sep 2004 14:21:48 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HLLmJB008594 for atom-protocol-skb; Fri, 17 Sep 2004 14:21:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8HLLl9B008588 for ; Fri, 17 Sep 2004 14:21:48 -0700 (PDT) (envelope-from rooneg@electricjellyfish.net) Received: (qmail 81111 invoked from network); 17 Sep 2004 21:21:52 -0000 Received: from inetuser.factset.com (HELO ?164.55.144.110?) (164.55.254.103) by relay.pair.com with SMTP; 17 Sep 2004 21:21:52 -0000 X-pair-Authenticated: 164.55.254.103 Message-ID: <414B556F.9060300@electricjellyfish.net> Date: Fri, 17 Sep 2004 17:21:51 -0400 From: Garrett Rooney User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <414B4B66.5050203@electricjellyfish.net> <20040917210023.GD3456@google.com> In-Reply-To: <20040917210023.GD3456@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > Take a look at your own work. "What? Feed optimization that requires > server work? An Apache module? We can't rely on that. Let's do something > that can be deployed by CGI scripts." That point of view would be very > short-sighed. Your work has already filled in the server needs. Heck, a > couple years from now, Apache might have native support for RFC 3229 with > plugins to perform the various differencing options. Well, my own work is just that, an optimization. And one that can layer on top of that CGI if you wanted it to. But that's not the point, I'm not saying I totally agree or disagree with the direction you want to take things in, I'm just trying to point out that there appears to be some kind of disconnect in people's assumptions, so getting that resolved sooner rather than later is probably a good thing. >>Since this seems like a fairly fundamental difference of opinion, >>perhaps it should be resolved first. What are the requirements we're >>willing to impose on implementors of the Atom API? > > > I was hoping to defer the discussion, generate a data model, and then > generate several protocol proposals around that model. One protocol could > be HTTP/WebDAV/REST styled, one could be a SOAP binding, and one could be > based (or whatever). I'd be concerned about having too many ways to do things. I'd prefer to have a single protocol than a family of them, just so I can be more certain that blogging client A and weblog software B are going to be able to talk to each other. -garrett From owner-atom-protocol Fri Sep 17 15:19:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMJpbL012867 for ; Fri, 17 Sep 2004 15:19:51 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HMJp7L012866 for atom-protocol-skb; Fri, 17 Sep 2004 15:19:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMJoCW012860 for ; Fri, 17 Sep 2004 15:19:51 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so529952rnb for ; Fri, 17 Sep 2004 15:19:52 -0700 (PDT) Received: by 10.38.8.29 with SMTP id 29mr258846rnh; Fri, 17 Sep 2004 15:19:52 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Fri, 17 Sep 2004 15:19:52 -0700 (PDT) Message-ID: <1f2ed5cd04091715197f7e65c9@mail.gmail.com> Date: Sat, 18 Sep 2004 00:19:52 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Greg Stein Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: Atom Protocol In-Reply-To: <20040917203425.GC13054@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504091511101115c5df@mail.gmail.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 13:34:25 -0700, Greg Stein wrote: > On Fri, Sep 17, 2004 at 08:39:49PM +0200, Danny Ayers wrote: > > Greg, one question: how does a client obtain the URI at which to apply > > the PROPFIND? > > I'm saying that you just PROPFIND on any page of the blog, and you get > back relevant information. But how do you get the address of the blog!? Where do you start from? I don't know about you, but a very large proportion of the URIs in the HTTP transactions in which my clients participate have directly come from, or come indirectly through, crufty unreliable HTML links. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Fri Sep 17 15:32:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMWMHj013564 for ; Fri, 17 Sep 2004 15:32:22 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HMWMTN013563 for atom-protocol-skb; Fri, 17 Sep 2004 15:32:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMWMu4013552 for ; Fri, 17 Sep 2004 15:32:22 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8HMVdsi022315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2004 15:31:40 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8RGV-0004UL-T6 by authid ; Fri, 17 Sep 2004 15:31:39 -0700 Date: Fri, 17 Sep 2004 15:31:39 -0700 From: Greg Stein To: Danny Ayers Cc: Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Message-ID: <20040917223139.GC14157@google.com> References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2ed5cd04091715197f7e65c9@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Sep 18, 2004 at 12:19:52AM +0200, Danny Ayers wrote: > On Fri, 17 Sep 2004 13:34:25 -0700, Greg Stein wrote: > > On Fri, Sep 17, 2004 at 08:39:49PM +0200, Danny Ayers wrote: > > > Greg, one question: how does a client obtain the URI at which to apply > > > the PROPFIND? > > > > I'm saying that you just PROPFIND on any page of the blog, and you get > > back relevant information. > > But how do you get the address of the blog!? Where do you start from? > > I don't know about you, but a very large proportion of the URIs in the > HTTP transactions in which my clients participate have directly come > from, or come indirectly through, crufty unreliable HTML links. I think we're disconnecting here somehow. I'll try to restate. We're talking about Atom-based tools, processes, etc. You have to feed them a URL somehow. Whether that's a cut/paste into my feed reader, or a ping to a service, or a toolbar extension. In most cases, the URL is going to be the front page of a blog. Some scenarios: * I'm viewing a blog and want to add it to my feed reader. I copy the URL from the address bar and paste it into a dialog on my reader. The reader does a PROPFIND and gets back the blog title, description, a URL to author information, a URL to the feed, a URL to a collection of entry resources, etc. * I update my blog with a post and my service sends a ping to feedster.com. Feedster takes the URL from the ping and does a PROPFIND to gather all the various bits. * I'm got a little "bookmarklet" installed in my browser. I just found a cool wiki page that I want to track. I hit the bookmarklet and it takes the current page, does a PROPFIND for the feed, and adds the feed to my browser's builtin feed reader. Yes, most of the URLs come from HTML and browsing. I think that I'm missing the point that you're trying to make. The URLs originate there, sure, but there is always going to be a step to move them elsewhere. Cheers, -g From owner-atom-protocol Fri Sep 17 15:53:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMr7sJ014683 for ; Fri, 17 Sep 2004 15:53:07 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HMr6OB014682 for atom-protocol-skb; Fri, 17 Sep 2004 15:53:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HMr6Jr014668 for ; Fri, 17 Sep 2004 15:53:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C8Rb6-0005UW-U9; Fri, 17 Sep 2004 22:52:57 +0000 Message-ID: <414B6AD9.4080003@franklinmint.fm> Date: Fri, 17 Sep 2004 18:53:13 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Stein CC: Danny Ayers , Atom Protocol Subject: Re: Introspection (was Re: ProtocolDataModelIssues) References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> In-Reply-To: <20040917223139.GC14157@google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Stein wrote: > > * I'm viewing a blog and want to add it to my feed reader. I copy the URL > from the address bar and paste it into a dialog on my reader. The reader > does a PROPFIND and gets back the blog title, description, a URL to > author information, a URL to the feed, a URL to a collection of entry > resources, etc. > Both of the programs I listed here: http://www.imc.org/atom-protocol/mail-archive/msg00066.html use autodiscovery to find feeds as the GET client is casually browsing. No cut/paste required. Robert Sayre From owner-atom-protocol Fri Sep 17 16:54:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HNss7A018791 for ; Fri, 17 Sep 2004 16:54:54 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8HNss19018790 for atom-protocol-skb; Fri, 17 Sep 2004 16:54:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8HNsrX7018784 for ; Fri, 17 Sep 2004 16:54:53 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i8HNtg4i011495 for ; Fri, 17 Sep 2004 19:55:45 -0400 Message-ID: <414B794B.4050104@intertwingly.net> Date: Fri, 17 Sep 2004 19:54:51 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom Protocol Subject: Bob vs PropFind References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> In-Reply-To: <20040917223139.GC14157@google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize for introducing a bit of experimental rigor to this debate. Client: import httplib connection = httplib.HTTPConnection("example.com") connection.request("PROPFIND", "/test.cgi", headers= {"Depth": "0"}) response = connection.getresponse() print response.read() Server: #!/usr/bin/python import os print "Content-Type: text/plain; charset=utf-8\r\n\r\n" print os.environ['REQUEST_METHOD'] Tentative conclusions: (1) Bob can support PropFind (2) Bob can produce non-well formed responses - Sam Ruby From owner-atom-protocol Fri Sep 17 17:14:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0ER8x019836 for ; Fri, 17 Sep 2004 17:14:27 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I0ER4X019835 for atom-protocol-skb; Fri, 17 Sep 2004 17:14:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0ERx7019827 for ; Fri, 17 Sep 2004 17:14:27 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 5163D47BF9; Fri, 17 Sep 2004 17:13:15 -0700 (PDT) In-Reply-To: <414B794B.4050104@intertwingly.net> References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> <414B794B.4050104@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Protocol From: Ezra Cooper Subject: Re: Bob vs PropFind Date: Fri, 17 Sep 2004 17:14:59 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 17, 2004, at 4:54 PM, Sam Ruby wrote: > > I apologize for introducing a bit of experimental rigor to this debate. > > [... code snipped ...] > > (1) Bob can support PropFind > (2) Bob can produce non-well formed responses What is the URL of this script? Can the webserver also serve up a static HTML page from that URL, when the request method is GET? Ezra From owner-atom-protocol Fri Sep 17 17:14:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0Ecwq019853 for ; Fri, 17 Sep 2004 17:14:38 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I0EcTv019852 for atom-protocol-skb; Fri, 17 Sep 2004 17:14:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0Eb0E019845 for ; Fri, 17 Sep 2004 17:14:37 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i8I0Eh53026127 for ; Fri, 17 Sep 2004 18:14:43 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I47007ZNNCIKJ@edgemail1.Central.Sun.COM> for atom-protocol@imc.org; Fri, 17 Sep 2004 18:14:43 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4700BYTNCH79@mail.sun.net> for atom-protocol@imc.org; Fri, 17 Sep 2004 18:14:42 -0600 (MDT) Date: Fri, 17 Sep 2004 17:14:39 -0700 From: Tim Bray Subject: Re: Bob vs PropFind In-reply-to: <414B794B.4050104@intertwingly.net> To: Sam Ruby Cc: Atom Protocol Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> <414B794B.4050104@intertwingly.net> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 17, 2004, at 4:54 PM, Sam Ruby wrote: > Tentative conclusions: > > (1) Bob can support PropFind Er, this relies on Bob either (a) having WebDAV installed & enabled, or (b) being able to run a script (as in your example) right? I believe Bob can only run scripts out of the ISP-designated cgi-bin directory (no .htaccess, remember), so he probably can't manage a PROPFIND on /index.html unless he's got WebDAV installed. So Bob is only halfway there. -Tim From owner-atom-protocol Fri Sep 17 17:53:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0r8E9022506 for ; Fri, 17 Sep 2004 17:53:08 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I0r8Bs022505 for atom-protocol-skb; Fri, 17 Sep 2004 17:53:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I0r8go022491 for ; Fri, 17 Sep 2004 17:53:08 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id B1AF347BF8; Fri, 17 Sep 2004 17:51:57 -0700 (PDT) In-Reply-To: <414A59BA.3030907@intertwingly.net> References: <414A59BA.3030907@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: atom-protocol@imc.org From: Ezra Cooper Subject: Re: Digest Auth in Atom Date: Fri, 17 Sep 2004 17:53:42 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 16, 2004, at 8:27 PM, Sam Ruby wrote: > Ezra Cooper wrote: >> As we've discussed a little bit in the past, some of the benefits of >> HTTP Digest authentication are: >> (1) Passwords need not be stored in the clear >> (2) Server chooses nonces and can determine how long it wants to >> keep them around >> (3) No problems with maladjusted clocks >> (4) Reasonably well-known and widely implemented >> These reasons, in particular number (1), make it very attractive for >> tools running in shared hosting environments, and we at Six Apart >> favor HTTP Digest over WSSE for becoming a part of the Atom spec. >> Is anyone else interested in working on this? I've got a working (at >> least, limping) implementation of HTTP Digest authentication within >> Movable Type's Atom implementation. Aside from using >> X-Atom-Authorization as the request header, I think it conforms to >> the spec. > > By #1, are you saying that things work out if you happen to have had > the foresight to store passwords on the server with the scheme defined > by digest authentication, or are you saying something more than that? Implementations might have to convert to the new hashing method, which is an inconvenience, but it's one that I'm willing to hurdle in order to establish an interoperable authentication method. > #4's wide implementation is somewhat reduced by use of the > non-standard header. That's true. But, as you say, the algorithm itself is known to the IETF and its security properties are known. > There is an aspect of challenge/response that should be discussed. An > HTTP GET request is relatively short, so a challenge is fairly > inexpensive. This is not as true for POST. Consider a cell phone > uploading a picture. > > This can be mitigated by careful use of a nextnonce, something which > requires careful design, library support, and single threading. Can you give some more details about the drawback here? Digest auth does have a technique to piggyback successive requests in a way that avoids double-requesting everything all the time (the nonce-count mechanism). So only the first request in a series would need an initial challenge request. Is that the same problem you have in mind? > We probably should consider what happens if md5 is cracked. > > - - - > > None of the above points are fatal. All in all, I believe that we > will find that: > > (1) We can't standardize on a single authentication method. Some > environments will require Kerberos, for example. In the event we can't standardize on a single method, how do we encourage interoperability? Can we highlight one or a small number of preferred methods? To encourage interop, can we make still make "changes," such as renaming the Authorization header? TLS is an attractive solution, but I believe that there will be clients and servers that are unable to support it. Without a second option, either some users will be Atom-less, or there will be a zoo of different variations of auth methods. For a second option, I much prefer Digest over WSSE. I'm not so worried about having different auth methods as I am about unstandardized variations on each method--e.g., different replacements for the Authorization header. It may make good sense to split Atom auth into a different spec. Thoughts on that? Ezra From owner-atom-protocol Fri Sep 17 18:33:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1XuOj025182 for ; Fri, 17 Sep 2004 18:33:56 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1Xufm025181 for atom-protocol-skb; Fri, 17 Sep 2004 18:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1XuFV025168 for ; Fri, 17 Sep 2004 18:33:56 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8I1Xr2b028390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Sep 2004 18:33:53 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8U6r-0005ke-Q7 by authid for ; Fri, 17 Sep 2004 18:33:53 -0700 Date: Fri, 17 Sep 2004 18:33:53 -0700 From: Greg Stein To: atom-protocol@imc.org Subject: Re: Digest Auth in Atom Message-ID: <20040918013353.GE3456@google.com> References: <414A59BA.3030907@intertwingly.net> <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 05:53:42PM -0700, Ezra Cooper wrote: >... > >None of the above points are fatal. All in all, I believe that we > >will find that: > > > > (1) We can't standardize on a single authentication method. Some > >environments will require Kerberos, for example. Agreed. > In the event we can't standardize on a single method, I really don't think we will be able to. Organizations have all kinds of policies around security, and they differ greatly. Two easy examples: 1) Google's intranet requires SSL to protect all password transmission 2) on my home network, I could care less. Basic in the clear is fine. There definitely won't be a single method. > how do we > encourage interoperability? Rely on plain old HTTP authentication. That has widespread support and is well-defined. Many, many clients and servers support it. Just leave it to the infrastructure and don't bother with it. > Can we highlight one or a small number of > preferred methods? Yes, definitely. See my previous notes about encouraging the avoidance of things like Basic (outside of a TLS/SSL pipe). > To encourage interop, can we make still make > "changes," such as renaming the Authorization header? Any changes to standard HTTP authentication systems will reduce interop. There are gazillions of tools and libraries and support systems which support the standards. Veer from that, and you reduce interop. > TLS is an attractive solution, but I believe that there will be clients > and servers that are unable to support it. Without a second option, > either some users will be Atom-less, or there will be a zoo of > different variations of auth methods. For a second option, I much > prefer Digest over WSSE. Agreed, all parts. > I'm not so worried about having different auth methods as I am about > unstandardized variations on each method--e.g., different replacements > for the Authorization header. > > It may make good sense to split Atom auth into a different spec. I don't think there *is* such a thing as "Atom auth". How is that different from HTTP authentication? And *why* would it be different? Cheers, -g From owner-atom-protocol Fri Sep 17 18:33:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1XfXL025159 for ; Fri, 17 Sep 2004 18:33:41 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1Xf9x025158 for atom-protocol-skb; Fri, 17 Sep 2004 18:33:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1Xed5025152 for ; Fri, 17 Sep 2004 18:33:40 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so302859rnl for ; Fri, 17 Sep 2004 18:33:46 -0700 (PDT) Received: by 10.38.125.2 with SMTP id x2mr336627rnc; Fri, 17 Sep 2004 18:33:46 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 18:33:46 -0700 (PDT) Message-ID: <14be96d304091718332851fc7c@mail.gmail.com> Date: Fri, 17 Sep 2004 21:33:46 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Sam Ruby Subject: Re: Bob vs PropFind Cc: Atom Protocol In-Reply-To: <414B794B.4050104@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> <414B794B.4050104@intertwingly.net> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize for introducing a bit of reality to this debate. http://www.cornerhost.com/plans/ Basic plan: $50/year, FTP only, "works with Blogger" Script plan: $100/year, CGI, "works with Movable Type" Perhaps we should change this to Basic plan: $50/year, FTP only, "works with RSS" Script plan: $100/year, CGI, "works with Atom" -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 18:42:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1gR2W026098 for ; Fri, 17 Sep 2004 18:42:27 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1gRml026097 for atom-protocol-skb; Fri, 17 Sep 2004 18:42:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1gQFk026091 for ; Fri, 17 Sep 2004 18:42:27 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so306291rnl for ; Fri, 17 Sep 2004 18:42:32 -0700 (PDT) Received: by 10.38.88.16 with SMTP id l16mr368223rnb; Fri, 17 Sep 2004 18:42:32 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 18:42:32 -0700 (PDT) Message-ID: <14be96d30409171842790c3cbe@mail.gmail.com> Date: Fri, 17 Sep 2004 21:42:32 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Ezra Cooper Subject: Re: Digest Auth in Atom Cc: Sam Ruby , atom-protocol@imc.org In-Reply-To: <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <414A59BA.3030907@intertwingly.net> <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 17:53:42 -0700, Ezra Cooper wrote: > It may make good sense to split Atom auth into a different spec. I support the idea of making a kind of "Digest Plus" RFC, a follow-up to RFC 2617 that standardizes more hashing algorithms (to cover all the different ways people are encrypting passwords in various applications, plus some newer variations of SHA that are felt to be more secure than SHA-1). And allows CGI-only applications like Movable Type to control it (such as through the non-standard header that Ezra mentioned 6A has already prototyped). I don't think we can do that alone though. At a minimum, we'd need massive buy-in from the security folks in the IETF. And possibly split off into a separate working group for it. -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 18:45:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1jCCn026253 for ; Fri, 17 Sep 2004 18:45:12 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1jCB5026252 for atom-protocol-skb; Fri, 17 Sep 2004 18:45:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1jBCi026241 for ; Fri, 17 Sep 2004 18:45:11 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 76so370407rnk for ; Fri, 17 Sep 2004 18:45:06 -0700 (PDT) Received: by 10.38.72.6 with SMTP id u6mr248536rna; Fri, 17 Sep 2004 18:45:05 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 18:45:05 -0700 (PDT) Message-ID: <14be96d30409171845756ddd08@mail.gmail.com> Date: Fri, 17 Sep 2004 21:45:05 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Greg Stein Subject: Re: Digest Auth in Atom Cc: atom-protocol@imc.org In-Reply-To: <20040918013353.GE3456@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <414A59BA.3030907@intertwingly.net> <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> <20040918013353.GE3456@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 18:33:53 -0700, Greg Stein wrote: > I don't think there *is* such a thing as "Atom auth". How is that > different from HTTP authentication? And *why* would it be different? For all the same reasons that we patiently explained to you the last time this issue came up. -- Cheers, -Mark From owner-atom-protocol Fri Sep 17 18:49:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1nXnc026576 for ; Fri, 17 Sep 2004 18:49:33 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1nXfS026575 for atom-protocol-skb; Fri, 17 Sep 2004 18:49:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1nWMH026567 for ; Fri, 17 Sep 2004 18:49:32 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (rdu57-27-065.nc.rr.com [66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i8I1o7o0018604; Fri, 17 Sep 2004 21:50:07 -0400 Message-ID: <414B941C.4080200@intertwingly.net> Date: Fri, 17 Sep 2004 21:49:16 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom Protocol Subject: Re: Bob vs PropFind References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> <414B794B.4050104@intertwingly.net> <14be96d304091718332851fc7c@mail.gmail.com> In-Reply-To: <14be96d304091718332851fc7c@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark Pilgrim wrote: > I apologize for introducing a bit of reality to this debate. > > http://www.cornerhost.com/plans/ > > Basic plan: $50/year, FTP only, "works with Blogger" > Script plan: $100/year, CGI, "works with Movable Type" > > Perhaps we should change this to > > Basic plan: $50/year, FTP only, "works with RSS" > Script plan: $100/year, CGI, "works with Atom" Are we talking about the same Bob? "Let's talk about Bob. Bob has a weblog. Bob hosts his weblog on a low-end web hosting service, one which hosts several hundred weblogs on a single machine (a single IP address). Bob can FTP files to his web directory, and he can run CGI scripts in Perl and Python." http://www.xml.com/pub/a/2003/12/17/dive.html - Sam Ruby From owner-atom-protocol Fri Sep 17 18:57:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1vqmW027049 for ; Fri, 17 Sep 2004 18:57:52 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I1vqfj027048 for atom-protocol-skb; Fri, 17 Sep 2004 18:57:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I1vqos027035 for ; Fri, 17 Sep 2004 18:57:52 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by 216-239-45-4.google.com (8.12.11/8.12.11) with ESMTP id i8I1vqpD004560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2004 18:57:52 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1C8UU4-0005ra-03 by authid ; Fri, 17 Sep 2004 18:57:52 -0700 Date: Fri, 17 Sep 2004 18:57:51 -0700 From: Greg Stein To: Mark Pilgrim Cc: atom-protocol@imc.org Subject: Re: Digest Auth in Atom Message-ID: <20040918015751.GF3456@google.com> References: <414A59BA.3030907@intertwingly.net> <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> <20040918013353.GE3456@google.com> <14be96d30409171845756ddd08@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14be96d30409171845756ddd08@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 17, 2004 at 09:45:05PM -0400, Mark Pilgrim wrote: > > On Fri, 17 Sep 2004 18:33:53 -0700, Greg Stein wrote: > > I don't think there *is* such a thing as "Atom auth". How is that > > different from HTTP authentication? And *why* would it be different? > > For all the same reasons that we patiently explained to you the last > time this issue came up. Boy... you're certainly an interesting person. I think that WSSE is just another form of HTTP authentication. It has nothing to do with Atom. And I don't think that Atom needs to care about the authentication scheme (my primary point). Just leave authentication to the "lower level" of HTTP, and concentrate on what the application is doing. I think the atom spec merely needs to make a recommendation in its security considerations section to say, "This protocol can be used to manipulate content on the server. Therefore, particular care should be taken to ensure that the client is properly authenticated, and that the credentials are properly secured." I'd describe WSSE as an authentication scheme implementable by CGI scripts. Quite handy, but very distinct from Atom. Cheers, -g From owner-atom-protocol Fri Sep 17 19:32:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I2WXJ5028537 for ; Fri, 17 Sep 2004 19:32:33 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I2WXMH028536 for atom-protocol-skb; Fri, 17 Sep 2004 19:32:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I2WWMk028529 for ; Fri, 17 Sep 2004 19:32:32 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so267071rnk for ; Fri, 17 Sep 2004 19:32:38 -0700 (PDT) Received: by 10.38.92.63 with SMTP id p63mr630702rnb; Fri, 17 Sep 2004 19:32:37 -0700 (PDT) Received: by 10.38.86.52 with HTTP; Fri, 17 Sep 2004 19:32:37 -0700 (PDT) Message-ID: <14be96d3040917193235b07a0e@mail.gmail.com> Date: Fri, 17 Sep 2004 22:32:37 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Sam Ruby Subject: Re: Bob vs PropFind Cc: Atom Protocol In-Reply-To: <414B941C.4080200@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> <414B794B.4050104@intertwingly.net> <14be96d304091718332851fc7c@mail.gmail.com> <414B941C.4080200@intertwingly.net> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 21:49:16 -0400, Sam Ruby wrote: > Are we talking about the same Bob? I'm not talking about Bob, because Greg is not talking about the Atom API. He's talking about replacing Atom Feed Autodiscovery, which currently works for all Blogger customers, with a method that does less and does not work for all Blogger customers. Someone else conflated this with the scenario I discussed in my XML.com article, which you so accurately quote below, and which has no bearing on this discussion about Atom Feed Autodiscovery. The correct character to use to talk about requirements for Atom Feed publishing and Atom Feed Autodiscovery is the UnprivilegedUser: http://intertwingly.net/wiki/pie/UnprivilegedUsers An UnprivilegedUser can not run your PROPFIND parlor trick, and no amount of misdirection about Bob will change that. > > "Let's talk about Bob. Bob has a weblog. Bob hosts his weblog on a > low-end web hosting service, one which hosts several hundred weblogs on > a single machine (a single IP address). Bob can FTP files to his web > directory, and he can run CGI scripts in Perl and Python." > > http://www.xml.com/pub/a/2003/12/17/dive.html > > - Sam Ruby > -- Cheers, -Mark From owner-atom-protocol Sat Sep 18 01:54:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I8sg5X025047 for ; Sat, 18 Sep 2004 01:54:42 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I8sgw1025046 for atom-protocol-skb; Sat, 18 Sep 2004 01:54:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I8sfk4025037 for ; Sat, 18 Sep 2004 01:54:41 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so782083rnb for ; Sat, 18 Sep 2004 01:54:38 -0700 (PDT) Received: by 10.38.8.32 with SMTP id 32mr249166rnh; Sat, 18 Sep 2004 01:54:38 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Sat, 18 Sep 2004 01:54:38 -0700 (PDT) Message-ID: <1f2ed5cd040918015478f6a34e@mail.gmail.com> Date: Sat, 18 Sep 2004 10:54:38 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Greg Stein Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: Atom Protocol In-Reply-To: <20040917223139.GC14157@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 15:31:39 -0700, Greg Stein wrote: > > > On Sat, Sep 18, 2004 at 12:19:52AM +0200, Danny Ayers wrote: > > On Fri, 17 Sep 2004 13:34:25 -0700, Greg Stein wrote: > > > On Fri, Sep 17, 2004 at 08:39:49PM +0200, Danny Ayers wrote: > > > > Greg, one question: how does a client obtain the URI at which to apply > > > > the PROPFIND? > We're talking about Atom-based tools, processes, etc. You have to feed > them a URL somehow. Whether that's a cut/paste into my feed reader, or a > ping to a service, or a toolbar extension. In most cases, the URL is going > to be the front page of a blog. My point was really that the client has got the URL somehow, whether it's pasted from another tool or autodiscovered, usually it will be lifted from somewhere on the HTTP 1.x web. The client has got to the front page of the blog with that system, it seems strange to suggest the client should now need WebDAV to get the other details. >Some scenarios: [snip - thanks] > * I'm viewing a blog and want to add it to my feed reader. I copy the URL > from the address bar and paste it into a dialog on my reader. The reader > does a PROPFIND and gets back the blog title, description, a URL to > author information, a URL to the feed, a URL to a collection of entry > resources, etc. Hmm - blog title, description and author info are delivered within the feed in the current specs, the URL to, and collection of entry resources will *be* the feed - so most of the time that will only be one URL. If the starting point is http://myblog.com and to get further the client does a PROPFIND (which I believe is what you're suggesting), then wouldn't it be easier to do a GET supplying the Atom mime type? >From the thread so far there doesn't seem to be much of a clamour to use PROPFIND, but I do think it's worthwhile exploring the options and not ruling anything out in advance. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Sat Sep 18 02:04:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I94FAt028109 for ; Sat, 18 Sep 2004 02:04:15 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I94Fia028108 for atom-protocol-skb; Sat, 18 Sep 2004 02:04:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I94FKp028066 for ; Sat, 18 Sep 2004 02:04:15 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so785180rnb for ; Sat, 18 Sep 2004 02:04:10 -0700 (PDT) Received: by 10.38.8.29 with SMTP id 29mr269929rnh; Sat, 18 Sep 2004 02:04:10 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Sat, 18 Sep 2004 02:04:10 -0700 (PDT) Message-ID: <1f2ed5cd0409180204170c6ac@mail.gmail.com> Date: Sat, 18 Sep 2004 11:04:10 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Mark Pilgrim Subject: Re: Bob vs PropFind Cc: Sam Ruby , Atom Protocol In-Reply-To: <14be96d3040917193235b07a0e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <1f2ed5cd04091715197f7e65c9@mail.gmail.com> <20040917223139.GC14157@google.com> <414B794B.4050104@intertwingly.net> <14be96d304091718332851fc7c@mail.gmail.com> <414B941C.4080200@intertwingly.net> <14be96d3040917193235b07a0e@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for showing Bob the door. He may be one end user, UnprivilegedUser may be another. But they aren't all users, and I don't think the right question is being asked. For those that *can* afford $100 (say IBM or Microsoft), is there any advantage in Atom including provision for WebDAV-based discovery? I don't personally think there is, but don't find the lowest common denominator reasoning sufficient in itself. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Sat Sep 18 02:28:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9SXD7036001 for ; Sat, 18 Sep 2004 02:28:33 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I9SXl7036000 for atom-protocol-skb; Sat, 18 Sep 2004 02:28:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9SWN2035989 for ; Sat, 18 Sep 2004 02:28:33 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so731303rnb for ; Sat, 18 Sep 2004 02:28:33 -0700 (PDT) Received: by 10.38.8.54 with SMTP id 54mr259817rnh; Sat, 18 Sep 2004 02:28:33 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Sat, 18 Sep 2004 02:28:33 -0700 (PDT) Message-ID: <1f2ed5cd04091802281a1a1442@mail.gmail.com> Date: Sat, 18 Sep 2004 11:28:33 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Greg Stein Subject: Re: Digest Auth in Atom Cc: Mark Pilgrim , atom-protocol@imc.org In-Reply-To: <20040918015751.GF3456@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <414A59BA.3030907@intertwingly.net> <2FAEA76E-090D-11D9-8753-000A95CFF6CC@sixapart.com> <20040918013353.GE3456@google.com> <14be96d30409171845756ddd08@mail.gmail.com> <20040918015751.GF3456@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 18:57:51 -0700, Greg Stein wrote: > I think the atom spec merely needs to make a recommendation in its > security considerations section to say, "This protocol can be used to > manipulate content on the server. Therefore, particular care should be > taken to ensure that the client is properly authenticated, and that the > credentials are properly secured." Given the importance of security I think it would be good to provide plenty of information, ideally with worked examples (like Mark's xml.com piece). But I agree with Greg in principle - Atom works *on top* of a security layer. Mixing authentication etc. into the spec may be useful for kickstarting implementations, but recently history has shown that's hardly needed, so it would do little more than narrow the applicability of Atom. > I'd describe WSSE as an authentication scheme implementable by CGI > scripts. Quite handy, but very distinct from Atom. +1 Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Sat Sep 18 02:42:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9gJFd041024 for ; Sat, 18 Sep 2004 02:42:19 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I9gJZm041023 for atom-protocol-skb; Sat, 18 Sep 2004 02:42:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I9gJEA041001 for ; Sat, 18 Sep 2004 02:42:19 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so796529rnb for ; Sat, 18 Sep 2004 02:42:20 -0700 (PDT) Received: by 10.38.8.32 with SMTP id 32mr249533rnh; Sat, 18 Sep 2004 02:42:20 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Sat, 18 Sep 2004 02:42:20 -0700 (PDT) Message-ID: <1f2ed5cd040918024262df3a2d@mail.gmail.com> Date: Sat, 18 Sep 2004 11:42:20 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Greg Stein Subject: Re: feed property (was: ProtocolDataModel issues) Cc: atom-protocol@imc.org In-Reply-To: <20040917033542.GI8305@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <14be96d304091618125d920554@mail.gmail.com> <20040917012513.GC8305@google.com> <14be96d3040916200916e734fe@mail.gmail.com> <20040917033542.GI8305@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 20:35:42 -0700, Greg Stein wrote: > It's really about using existing mechanism, rather than coming > up with new stuff. The autodiscovery mechanism (specifically the construct) has been around since before HTML got version numbers. All that's new is a tighter, clearer formalization of syntax requirements to clarify how the mechanism is used alongside Atom applications. Cheers, Danny. -- http://dannyayers.com From owner-atom-protocol Sat Sep 18 03:20:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IAKbhr054700 for ; Sat, 18 Sep 2004 03:20:37 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IAKbdp054698 for atom-protocol-skb; Sat, 18 Sep 2004 03:20:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IAKaUY054666 for ; Sat, 18 Sep 2004 03:20:37 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so807873rnb for ; Sat, 18 Sep 2004 03:20:31 -0700 (PDT) Received: by 10.38.8.32 with SMTP id 32mr249842rnh; Sat, 18 Sep 2004 03:20:31 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Sat, 18 Sep 2004 03:20:31 -0700 (PDT) Message-ID: <1f2ed5cd04091803206388b090@mail.gmail.com> Date: Sat, 18 Sep 2004 12:20:31 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Ezra Cooper Subject: Re: ProtocolDataModel issues Cc: Atom Protocol In-Reply-To: <5D1603F1-084A-11D9-BC18-000A95CFF6CC@sixapart.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <5D1603F1-084A-11D9-BC18-000A95CFF6CC@sixapart.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004 18:39:06 -0700, Ezra Cooper wrote: > > I had understood that on this team we'd be talking about issues related > to manipulating the server's objects, including objects that are not > normally represented in a "feed" (list of entries). In order to do that > we should set a scope: which objects do we want to be able to > manipulate using Atom? Here's my proposal: > > * Entries > * Authors (Users, Principals) > * Feeds/Blogs/Channels/Streams/... > * Categories > * Templates The format spec provides a reasonable prose definition of Entries, Authors, Feeds and their associated slots of data (using Content Constructs, Person Constructs, Date Constructs, Link Constructs). > A Category has properties: name, URI, and (optionally) a type. The type > could identify a categorization system in which this category > participates, if it's helpful to know that. > > A Template has properties: title, content, URI, MIME Type. It would be useful to see these defined in a similar way to the model defined in the format spec. Could you give examples of how these would be used - what kind of transactions? How they would appear in XML syntax? Various folks are working on other schemas and formal modelling. Some of us are attempting to express Atom in RDF/OWL (see [1], [2]), so anything that may help putting Categories and Templates into that model would be appreciated. Cheers, Danny. [1] http://bblfish.net/work/atom-owl/2004-08-12/blogexample.html [2] http://semtext.org/atom/ -- http://dannyayers.com From owner-atom-protocol Sat Sep 18 04:54:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IBso7v073636 for ; Sat, 18 Sep 2004 04:54:50 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8IBsov1073635 for atom-protocol-skb; Sat, 18 Sep 2004 04:54:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8IBslwu073623 for ; Sat, 18 Sep 2004 04:54:50 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id DD5D07C2EB; Sat, 18 Sep 2004 14:43:57 +0200 (CEST) Date: Sat, 18 Sep 2004 13:57:44 +0200 To: "Tim Bray" , "Robert Sayre" Subject: Re: Introspection (was Re: ProtocolDataModelIssues) Cc: "Atom Protocol" , "Garrett Rooney" , "Greg Stein" , "Danny Ayers" , "Ken MacLeod" References: <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <20040916181649.GD9997@google.com> <414A2E23.8050309@intertwingly.net> <20040917003559.GA8305@google.com> <67820488-084B-11D9-BC18-000A95CFF6CC@sixapart.com> <20040917021752.GE8305@google.com> <1f2ed5cd04091711392fd8f0db@mail.gmail.com> <20040917203425.GC13054@google.com> <414B4B66.5050203@electricjellyfish.net> <414B4F42.3050605@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Sep 2004 14:08:32 -0700, Tim Bray wrote: >> I don't consider PROPFIND on "index.html" to be a compelling enough >> feature to increase requirements for server implementations. That >> doesn't mean I'm against defining Atom-specific properties for a >> PROPFIND. +1. > [...] but it seems to me that autodiscovery via HTML is is > well-established and well-debugged and it would be silly for Atom > to walk away from it. Although I don't find the HTML autodiscovery mechanism to be very elegant, it's currently the only universally available mechanism we can settle for. PROPFIND may be a richer alternative, but we can't rely on its support. > Having said that, Greg has made some good points and the PROPFIND in > particular looks compelling. Yes, it's a powerful method. Although Ken MacLeod has been absent from this thread, I think he's in favour of using more of WebDAV in the Atom protocol as well. Isn't that right, Ken? > [...] But I don't see how we can do that without an actual proposal to > look at. I agree. -- Asbjřrn Ulsberg -=|=- http://virtuelvis.com/quark/ ŤHe's a loathsome offensive brute, yet I can't look awayť From owner-atom-protocol Mon Sep 20 16:54:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KNsI0K043204 for ; Mon, 20 Sep 2004 16:54:18 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8KNsIuA043203 for atom-protocol-skb; Mon, 20 Sep 2004 16:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8KNsIsK043192 for ; Mon, 20 Sep 2004 16:54:18 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id 484BA47BF9; Mon, 20 Sep 2004 16:52:52 -0700 (PDT) In-Reply-To: <1f2ed5cd04091803206388b090@mail.gmail.com> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <5D1603F1-084A-11D9-BC18-000A95CFF6CC@sixapart.com> <1f2ed5cd04091803206388b090@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7704D093-0B60-11D9-82D6-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: Atom Protocol From: Ezra Cooper Subject: Template Constructs (was Re: ProtocolDataModel issues) Date: Mon, 20 Sep 2004 16:54:52 -0700 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 18, 2004, at 3:20 AM, Danny Ayers wrote: > It would be useful to see these defined in a similar way to the model > defined in the format spec. Could you give examples of how these would > be used - what kind of transactions? I posted PaceTemplateConstruct as a step in this direction. As to the operations supported, only fetches and updates would be needed for templates. On further reflection I noticed that the template construct is not much different from a content construct. I don't see any problem with using the content construct for templates. Assuming we have a good way to represent the templates themselves, what's the best way for clients to discover them? If we have a resource containing a list of the templates' URLs, then we could discover the URL of that list from the contents at the FeedURI. Does that sound like a reasonable use of the FeedURI? Ezra From owner-atom-protocol Mon Sep 20 17:02:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L02vmQ044186 for ; Mon, 20 Sep 2004 17:02:57 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8L02vY1044185 for atom-protocol-skb; Mon, 20 Sep 2004 17:02:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L02uAV044175 for ; Mon, 20 Sep 2004 17:02:56 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so3454012rnl for ; Mon, 20 Sep 2004 17:02:52 -0700 (PDT) Received: by 10.38.79.75 with SMTP id c75mr873967rnb; Mon, 20 Sep 2004 17:02:51 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Mon, 20 Sep 2004 17:02:51 -0700 (PDT) Message-ID: <3f1451f5040920170218d57004@mail.gmail.com> Date: Mon, 20 Sep 2004 20:02:51 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Greg Stein Subject: Re: Welcome Cc: atom-protocol@imc.org In-Reply-To: <20040908203731.GA6232@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f5040908085138aad36c@mail.gmail.com> <3f1451f5040908085467fb7821@mail.gmail.com> <20040908203731.GA6232@google.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Sep 2004 13:37:31 -0700, Greg Stein wrote: > > This is certainly a valid approach to begin discussion -- what is being > done today is a good demonstration of "what is needed?" However, I'd like > to propose a different path for tackling the problem. Something a bit more > methodical: > > * identify and design the data model > - what objects are represented? > - what properties do they have? > - what are the relationships? > > * identify the operations needed to operate on the data model > > * define the protocol around the above items This has been an interesting experiment that I have watched for the past two weeks. Unfortunately not much has been achieved. I am going to start producing a series of Paces to focus the discussion. The first one I am puttig forward is PaceIntrospection. The next few will be concrete, they will presume HTTP + 4 verbs, and they will also presume PaceIntrospection. Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Mon Sep 20 17:04:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L04BV9044282 for ; Mon, 20 Sep 2004 17:04:11 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8L04BgQ044281 for atom-protocol-skb; Mon, 20 Sep 2004 17:04:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L04Ajb044275 for ; Mon, 20 Sep 2004 17:04:11 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so3455346rnl for ; Mon, 20 Sep 2004 17:04:16 -0700 (PDT) Received: by 10.38.99.13 with SMTP id w13mr3074232rnb; Mon, 20 Sep 2004 17:04:16 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Mon, 20 Sep 2004 17:04:15 -0700 (PDT) Message-ID: <3f1451f504092017045cf3a023@mail.gmail.com> Date: Mon, 20 Sep 2004 20:04:15 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Atom Protocol Subject: PaceIntrospection Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: == Abstract == Older versions of the AtomAPI had a file called the Introspection file. This file listed all of the different facets that a site supported. Real world experience has shown that this is a needed part of the API and this Pace reintroduces the concept with some minor changes. == Status == Open == Related and Conflicting Proposals == * PaceServiceElement * PaceSiteMap == Key Questions == * Should we create new atom:introspection and atom:site elements for the introspection format, or can atom:feed and atom:entry fill those roles? * Is "introspection" an appropriate name? * What services does introspection need to expose? (See PaceServiceElement for a possible enumeration). * What resources should be introspectable? Sites? Feeds? Individual users of a site? == Proposal == Add the following to Section 5, the Functional Specification: When editing the content of the website http://example.org/reilly, the first thing to do is find out the servers capabilites. Each server may only implement a subset of this specification, and the 'introspection' file lists all the functions that each site supports. {{{ }}} Each element in represents a single facet of the AtomAPI. While a site must fully support each facet they list in their introspection file, a site does not need to support all the facets in this RFC. Additionally, new facets may be added either through vendor extension or follow-on RFCs. Note that the example URIs given are not normative, nor are there any constraints on the URIs that can be specified. The 'service.post' URI could just have easily been: http://dev.example.net/api?userid=reilly&action=create 5.1.1 Introspection Discovery The element has been successful in finding RSS feeds and is appropriate to use here for discovering the location of the Introspection file. The tag goes in the section of an HTML page and is used to indicate a document relationship. For a similar example of using the link tag to discover a URI, refer to the usage of of the link tag for RSS Auto-Discovery. In this case the form of the link tag used to indicate the location of the comment URI is: Where href should be set to the URI of the Introspection file. Applications looking for the Introspection file to need to parse out the headers of the web page and look for a link tag that has a relation rel of "service.edit" and a mime-type of "application/atom+xml". == Rationale == A file similar to this format existed in previous drafts of the AtomAPI. It was dropped because it appeared to add more complexity to the API. Unfortunately it was dropped before there was much real world experience with the API. Since then SixApart and Blogger have both implemented the AtomAPI and one of the first things they did was to create a file that was similar in spirit to the introspection file. With both TypePad and Blogger a single user may have more than one site they manage. A single point of access was needed that enumerated all the sites that a user in managing and also lists all the facets that the service supports. Both SixApart and Blogger chose to use the Atom feed format for their file, but it does have the problem that the 'sites' listed in the file are not cleanly delineated. Here for example is an example file from my TypePad account: {{{ }}} Note that this represents two sites, the main site and my link log. == Impacts == This changes undocumented functionality already deployed in the field. -- Joe Gregorio http://bitworking.org From owner-atom-protocol Mon Sep 20 17:11:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0BHEu044755 for ; Mon, 20 Sep 2004 17:11:17 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8L0BH11044754 for atom-protocol-skb; Mon, 20 Sep 2004 17:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0BG4r044747 for ; Mon, 20 Sep 2004 17:11:16 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9YFd-0001iY-R0; Tue, 21 Sep 2004 00:11:21 +0000 Message-ID: <414F71A6.4060304@franklinmint.fm> Date: Mon, 20 Sep 2004 20:11:18 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Atom Protocol Subject: Re: PaceIntrospection References: <3f1451f504092017045cf3a023@mail.gmail.com> In-Reply-To: <3f1451f504092017045cf3a023@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe Gregorio wrote: > > Each element in represents a single facet of the AtomAPI. While > a site must fully support each facet they list in their introspection > file, a site does not need to support all the facets in this RFC. > Additionally, new facets may be added either through vendor extension > or follow-on RFCs. > What are the constraints on these elements? For example, can I nest elements? Robert Sayre From owner-atom-protocol Mon Sep 20 17:45:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0j6as048126 for ; Mon, 20 Sep 2004 17:45:06 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8L0j6ZT048125 for atom-protocol-skb; Mon, 20 Sep 2004 17:45:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0j5R4048109 for ; Mon, 20 Sep 2004 17:45:06 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so3494142rnl for ; Mon, 20 Sep 2004 17:45:06 -0700 (PDT) Received: by 10.38.79.75 with SMTP id c75mr902775rnb; Mon, 20 Sep 2004 17:45:06 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Mon, 20 Sep 2004 17:45:06 -0700 (PDT) Message-ID: <3f1451f50409201745224a9ce5@mail.gmail.com> Date: Mon, 20 Sep 2004 20:45:06 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Atom Protocol Subject: PaceCategoriesFacet Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This facet adds an interface to query for category information. http://intertwingly.net/wiki/pie/PaceCategoriesFacet ------------------------------------------------------ == Abstract == Adds the ability to query a site for a list of acceptable categories. == Status == Open Author: JoeGregorio == Rationale == Categories are part of the original charter for the atompub working group, and in addition they are showing up in the wild: http://sixapart.com/developers/atom/typepad/ == Proposal == Add the following to the protocol specification: 3.4 CategoryURI The CategoryURI allows the client application to retrieve a list of category name-value pairs from the server. These name-value pairs are presented to the user to choose from when creating or updating an entry. The value of the name-value pair is sent in a dc:subject element of the entry. 3.4.1 Locating The CategoryURI is found in the Introspection file. If the server supports a specific type of categorization then it SHOULD present a category facet in it's Introspection file. The 'name' for the CategoryURI in the Introspection file is 'categories'. {{{ . . }}} 3.4.2 Request The only method specified for this URI is GET. 3.4.3 Response The response from a successful GET on a CategoryURI is an XML formatted as follows: {{{ Books Travel Movies }}} Given the above example response, if a new entry was created with a movie review it can be categorized by adding the following element to the POSTed entry: {{{ . http://example.net/myontology/#movies . }}} The mime-type of the returned content is 'application/atom+xml'. Any number of children 'atom:subject' elements may be present. == Key Questions == 1. What do we do for large categorization schemes? For example, if I recall correctly just the category names for DMOZ totals over 300MB. 2. Do we need to indicate somewhere which categorization schema this is from, either something private, or indicate it is from a well known source, such as IPTC, DMOZ, etc. 3. Does this work for all the 'well-known' categorization schemes? 4. Are multiple dc:subject elements allowed in an entry? How do we distinguish if only 1 or if more are allowed? == Impacts == == Notes == CREDIT: This idea and interface is inspired by the TypePad implementation: http://sixapart.com/developers/atom/typepad/ Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Mon Sep 20 17:53:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0rVXn048897 for ; Mon, 20 Sep 2004 17:53:31 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8L0rVbp048896 for atom-protocol-skb; Mon, 20 Sep 2004 17:53:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L0rVgC048878 for ; Mon, 20 Sep 2004 17:53:31 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9YuT-00021H-Ue; Tue, 21 Sep 2004 00:53:34 +0000 Message-ID: <414F7B8B.5030902@franklinmint.fm> Date: Mon, 20 Sep 2004 20:53:31 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Atom Protocol Subject: Re: PaceCategoriesFacet References: <3f1451f50409201745224a9ce5@mail.gmail.com> In-Reply-To: <3f1451f50409201745224a9ce5@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe Gregorio wrote: > This facet adds an interface to query for category information. > > http://intertwingly.net/wiki/pie/PaceCategoriesFacet > What are the definitions of the elements and attributes introduced? Robert Sayre From owner-atom-protocol Mon Sep 20 18:06:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L16AvK050357 for ; Mon, 20 Sep 2004 18:06:10 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8L16AM2050356 for atom-protocol-skb; Mon, 20 Sep 2004 18:06:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8L169oT050350 for ; Mon, 20 Sep 2004 18:06:09 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9Z6k-0004l7-Tq for atom-protocol@imc.org; Tue, 21 Sep 2004 01:06:15 +0000 Message-ID: <414F7E84.1030104@franklinmint.fm> Date: Mon, 20 Sep 2004 21:06:12 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Protocol Subject: PaceMoveLinkElement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://www.intertwingly.net/wiki/pie/PaceMoveLinkElement == Abstract == Move the definition of the Link element to the Format Spec. == Status == Open[[BR]] == Rationale == The definition of the document format belongs in the format spec. == Proposal == Move the definition of the Link element to the Format Spec. == Impacts == Atom Format Spec readers can read one document, and the Atom Protocol spec can get out of the format business. From owner-atom-protocol Tue Sep 21 05:18:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCIEvg020705 for ; Tue, 21 Sep 2004 05:18:14 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LCIERd020704 for atom-protocol-skb; Tue, 21 Sep 2004 05:18:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCIDwp020698 for ; Tue, 21 Sep 2004 05:18:14 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so1896555rnb for ; Tue, 21 Sep 2004 05:18:15 -0700 (PDT) Received: by 10.38.8.54 with SMTP id 54mr94044rnh; Tue, 21 Sep 2004 05:18:15 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Tue, 21 Sep 2004 05:18:15 -0700 (PDT) Message-ID: <1f2ed5cd0409210518774b9458@mail.gmail.com> Date: Tue, 21 Sep 2004 14:18:15 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Joe Gregorio Subject: Re: PaceCategoriesFacet Cc: Atom Protocol In-Reply-To: <3f1451f50409201745224a9ce5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f50409201745224a9ce5@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Generally looks good to me. > == Key Questions == > > 1. What do we do for large categorization schemes? For example, if I > recall correctly just the category names for DMOZ totals over 300MB. Do whatever any other API request will do when the results are large..? (HTTP 208 Brace Yourself) > 2. Do we need to indicate somewhere which categorization schema this > is from, either something private, or indicate it is from a well > known source, such as IPTC, DMOZ, etc. I think so - the per-cat URI should be enough, but having a collective URI would very likely be useful in implementation. Should make it easier to hook into systems like SKOS [1] for a start. > 3. Does this work for all the 'well-known' categorization schemes? The only potential problem that jumps out at me is the i18n one - you're effectively dealing with label,URI pairs. The category may be the same but the label may be different - dog/chien. Not sure if would actually impact though, the category scheme maintainer should be looking after stuff like that (one category, multiple alternate labels). > 4. Are multiple dc:subject elements allowed in an entry? How do we > distinguish if only 1 or if more are allowed? Yes, definitely. Discovery sounds like an introspection task, capabilities stuff - where's other, similar stuff going? Cheers, Danny. [1] http://www.w3.org/2001/sw/Europe/reports/thes/1.0/guide/ -- http://dannyayers.com From owner-atom-protocol Tue Sep 21 05:20:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCKcTK020871 for ; Tue, 21 Sep 2004 05:20:38 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LCKcvo020870 for atom-protocol-skb; Tue, 21 Sep 2004 05:20:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCKcsp020864 for ; Tue, 21 Sep 2004 05:20:38 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so1897046rnb for ; Tue, 21 Sep 2004 05:20:36 -0700 (PDT) Received: by 10.38.11.80 with SMTP id 80mr93931rnk; Tue, 21 Sep 2004 05:20:36 -0700 (PDT) Received: by 10.38.179.32 with HTTP; Tue, 21 Sep 2004 05:20:36 -0700 (PDT) Message-ID: <1f2ed5cd040921052047c0c8ee@mail.gmail.com> Date: Tue, 21 Sep 2004 14:20:36 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Joe Gregorio Subject: Re: PaceCategoriesFacet Cc: Atom Protocol In-Reply-To: <1f2ed5cd0409210518774b9458@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f50409201745224a9ce5@mail.gmail.com> <1f2ed5cd0409210518774b9458@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Sep 2004 14:18:15 +0200, Danny Ayers wrote: > > 2. Do we need to indicate somewhere which categorization schema this > > is from, either something private, or indicate it is from a well > > known source, such as IPTC, DMOZ, etc. > > I think so - the per-cat URI should be enough, but having a collective > URI would very likely be useful in implementation. Should make it > easier to hook into systems like SKOS [1] for a start. PS. (Somehow) it should still be possible to include terms from multiple schema. Not sure how... -- http://dannyayers.com From owner-atom-protocol Tue Sep 21 05:31:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCVkGU021784 for ; Tue, 21 Sep 2004 05:31:46 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LCVkv6021783 for atom-protocol-skb; Tue, 21 Sep 2004 05:31:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LCVjMj021777 for ; Tue, 21 Sep 2004 05:31:46 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so2295101rnl for ; Tue, 21 Sep 2004 05:31:47 -0700 (PDT) Received: by 10.38.82.75 with SMTP id f75mr2539308rnb; Tue, 21 Sep 2004 05:31:47 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 05:31:47 -0700 (PDT) Message-ID: <3f1451f50409210531710dc90a@mail.gmail.com> Date: Tue, 21 Sep 2004 08:31:47 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PaceIntrospection Cc: Atom Protocol In-Reply-To: <414F71A6.4060304@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504092017045cf3a023@mail.gmail.com> <414F71A6.4060304@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Sep 2004 20:11:18 -0400, Robert Sayre wrote: > Joe Gregorio wrote: > > > > > Each element in represents a single facet of the AtomAPI. While > > a site must fully support each facet they list in their introspection > > file, a site does not need to support all the facets in this RFC. > > Additionally, new facets may be added either through vendor extension > > or follow-on RFCs. > > > > What are the constraints on these elements? For example, can I nest > elements? Note that I updated the format to reflect PaceServiceElement. In the notation of a DTD, modulo the namespace: Here is an example for reference: -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 06:37:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LDb62l029731 for ; Tue, 21 Sep 2004 06:37:06 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LDb6Yi029730 for atom-protocol-skb; Tue, 21 Sep 2004 06:37:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LDb5iR029688 for ; Tue, 21 Sep 2004 06:37:06 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4159596rnl for ; Tue, 21 Sep 2004 06:37:02 -0700 (PDT) Received: by 10.38.74.50 with SMTP id w50mr2668248rna; Tue, 21 Sep 2004 06:37:02 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 06:37:02 -0700 (PDT) Message-ID: <3f1451f504092106372afc5f79@mail.gmail.com> Date: Tue, 21 Sep 2004 09:37:02 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PaceCategoriesFacet Cc: Atom Protocol In-Reply-To: <414F7B8B.5030902@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f50409201745224a9ce5@mail.gmail.com> <414F7B8B.5030902@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Sep 2004 20:53:31 -0400, Robert Sayre wrote: > Joe Gregorio wrote: > > > This facet adds an interface to query for category information. > > > > http://intertwingly.net/wiki/pie/PaceCategoriesFacet > > > > What are the definitions of the elements and attributes introduced? In the notation of a DTD, modulo the namespace: Books Travel Movies The 'atom:subject' element conveys human-readable information about a single category. The content of the 'value' attribute of the 'atom:subject' element is the value to be submitted in a dc:subject element of an entry. It does not have to be human-readable. The formatting of the content is determined by the categorization schema chosen. For example, here is a fragment of a categories document for a site that is using the ITPC NewsCodes[1] : . archaeology architecture cinema . I will update the Pace with this added verbage. [1] http://www.iptc.org/NewsCodes/nc_ts-table01.php -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 07:08:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LE8PFm033247 for ; Tue, 21 Sep 2004 07:08:25 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LE8PuJ033246 for atom-protocol-skb; Tue, 21 Sep 2004 07:08:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LE8Ow6033238 for ; Tue, 21 Sep 2004 07:08:24 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4187451rnl for ; Tue, 21 Sep 2004 07:08:26 -0700 (PDT) Received: by 10.38.79.75 with SMTP id c75mr1464503rnb; Tue, 21 Sep 2004 07:08:26 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 07:08:24 -0700 (PDT) Message-ID: <3f1451f504092107083ea859e3@mail.gmail.com> Date: Tue, 21 Sep 2004 10:08:24 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PaceIntrospection Cc: Atom Protocol In-Reply-To: <3f1451f50409210531710dc90a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504092017045cf3a023@mail.gmail.com> <414F71A6.4060304@franklinmint.fm> <3f1451f50409210531710dc90a@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://intertwingly.net/wiki/pie/PaceIntrospection has been updated to include detailed descriptions of the elements and attibutes of the introspection document. Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 07:10:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEAT4b033504 for ; Tue, 21 Sep 2004 07:10:29 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LEAT3J033503 for atom-protocol-skb; Tue, 21 Sep 2004 07:10:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEASG0033493 for ; Tue, 21 Sep 2004 07:10:28 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4189087rnl for ; Tue, 21 Sep 2004 07:10:27 -0700 (PDT) Received: by 10.38.82.34 with SMTP id f34mr1373065rnb; Tue, 21 Sep 2004 07:10:26 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 07:10:26 -0700 (PDT) Message-ID: <3f1451f504092107106ec4e3b4@mail.gmail.com> Date: Tue, 21 Sep 2004 10:10:26 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PaceIntrospection Cc: Atom Protocol In-Reply-To: <3f1451f504092107083ea859e3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504092017045cf3a023@mail.gmail.com> <414F71A6.4060304@franklinmint.fm> <3f1451f50409210531710dc90a@mail.gmail.com> <3f1451f504092107083ea859e3@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Copied here for completeness: == Abstract == Older versions of the AtomAPI had a file called the Introspection file. This file listed all of the different facets that a site supported. Real world experience has shown that this is a needed part of the API and this Pace reintroduces the concept with some minor changes. == Status == Open == Related and Conflicting Proposals == * PaceServiceElement * PaceSiteMap == Key Questions == * Should we create new atom:introspection and atom:site elements for the introspection format, or can atom:feed and atom:entry fill those roles? * Is "introspection" an appropriate name? * What services does introspection need to expose? (See PaceServiceElement for a possible enumeration). * What resources should be introspectable? Sites? Feeds? Individual users of a site? == Proposal == Add the following to Section 5, the Functional Specification: 3.X InstrospectionURI When editing the content of the website http://example.org/reilly, the first thing to do is find out the servers capabilites. Each server may only implement a subset of this specification, and the 'introspection' document lists all the functions that each site supports. The IntrospectionURI returns an Introspection document in response to a GET request. Here is an example of an Introspection document. {{{ }}} Each 'service' element in represents a single facet of the AtomAPI. While a site must fully support each facet they list in their introspection document, a site does not need to support all the facets in this RFC. Additionally, new facets may be added either through vendor extension or follow-on RFCs. Note that the example URIs given are not normative, nor are there any constraints on the URIs that can be specified. The PostURI could just have easily been: http://dev.example.net/api?userid=reilly&action=create 3.X.1 Introspection Discovery The element has been successful in finding RSS feeds and is appropriate to use here for discovering the location of the Introspection document. The tag goes in the section of an HTML page and is used to indicate a document relationship. For a similar example of using the link tag to discover a URI, refer to the usage of of the link tag for RSS Auto-Discovery. In this case the form of the link tag used to indicate the location of the comment URI is: Where href should be set to the URI of the Introspection file. Applications looking for the Introspection file to need to parse out the headers of the web page and look for a link tag that has a relation rel of "service.introspection" and a mime-type of "application/atom+xml". 3.X.2 Request The only method specified for the IntrospectionURI is GET. 3.X.3 Response The response from a successful GET request to an IntrospectionURI is an Introspection document. 3.X.3.1 The 'atom:introspection' element The "atom:introspection" element is the document (i.e., top-level) element of an Introspection Document, acting as a container for service data associated with possibly multiple sites. Its only child elements MUST be one or more atom:site elements. The "atom:introspection" element MUST have a single attribute 'version' whose content indicates the version of the Atom specification that the feed conforms to. The content of this attribute is unstructured text. The version identifier for this specification is "1.0". 3.X.3.2 The 'atom:site' element The "atom:site" element contains information elements about the services of a single site. The only children of "atom:site" MUST be one or more "atom:service" elements. The "atom:site" element MUST have a single attribute 'title' whose content MUST NOT be empty and which is a human-readable name for the site. 3.X.3.2 The 'atom:service' element See PaceServiceElement for a description of this element and it's arributes. == Rationale == A file similar to this format existed in previous drafts of the AtomAPI. It was dropped because it appeared to add more complexity to the API. Unfortunately it was dropped before there was much real world experience with the API. Since then SixApart and Blogger have both implemented the AtomAPI and one of the first things they did was to create a file that was similar in spirit to the introspection file. With both TypePad and Blogger a single user may have more than one site they manage. A single point of access was needed that enumerated all the sites that a user in managing and also lists all the facets that the service supports. Both SixApart and Blogger chose to use the Atom feed format for their file, but it does have the problem that the 'sites' listed in the file are not cleanly delineated. Here for example is an example file from my TypePad account: {{{ }}} Note that this represents two sites, the main site and my link log. == Impacts == This changes undocumented functionality already deployed in the field. == Notes == Updated to follow PaceServiceElement. Updated to use the term 'document' instead of 'file'. Updated to include detailed descriptions of the attributes and elements of the introspection document. -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 07:17:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEHBfZ034056 for ; Tue, 21 Sep 2004 07:17:11 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LEHBTC034055 for atom-protocol-skb; Tue, 21 Sep 2004 07:17:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEHAt0034048 for ; Tue, 21 Sep 2004 07:17:10 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9lS7-0004An-In; Tue, 21 Sep 2004 14:17:07 +0000 Message-ID: <415037DA.9040309@franklinmint.fm> Date: Tue, 21 Sep 2004 10:16:58 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Atom Protocol Subject: Introspection and Category Documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://intertwingly.net/wiki/pie/PaceIntrospection http://intertwingly.net/wiki/pie/PaceCategoriesFacet These Paces detail the representation of resources termed "documents", which seems a little circular to me. What kind of resources are these? Category Collections? Accounts? Domains? What's a "site"? Robert Sayre From owner-atom-protocol Tue Sep 21 07:36:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEawUM036426 for ; Tue, 21 Sep 2004 07:36:58 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LEawA2036425 for atom-protocol-skb; Tue, 21 Sep 2004 07:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEavao036418 for ; Tue, 21 Sep 2004 07:36:58 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4213034rnl for ; Tue, 21 Sep 2004 07:37:00 -0700 (PDT) Received: by 10.38.15.66 with SMTP id 66mr2979142rno; Tue, 21 Sep 2004 07:36:59 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 07:36:59 -0700 (PDT) Message-ID: <3f1451f50409210736187456bb@mail.gmail.com> Date: Tue, 21 Sep 2004 10:36:59 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PaceCategoriesFacet Cc: Atom Protocol In-Reply-To: <3f1451f504092106372afc5f79@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f50409201745224a9ce5@mail.gmail.com> <414F7B8B.5030902@franklinmint.fm> <3f1451f504092106372afc5f79@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://intertwingly.net/wiki/pie/PaceCategoriesFacet has been update with more information on the attribute and element meanings. Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 07:42:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEg0Z2037028 for ; Tue, 21 Sep 2004 07:42:00 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LEfx6o037027 for atom-protocol-skb; Tue, 21 Sep 2004 07:41:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEfxI7037020 for ; Tue, 21 Sep 2004 07:41:59 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4217892rnl for ; Tue, 21 Sep 2004 07:42:01 -0700 (PDT) Received: by 10.38.82.34 with SMTP id f34mr1409245rnb; Tue, 21 Sep 2004 07:41:59 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 07:41:59 -0700 (PDT) Message-ID: <3f1451f5040921074173266f27@mail.gmail.com> Date: Tue, 21 Sep 2004 10:41:59 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: mint@franklinmint.fm Subject: Re: Introspection and Category Documents Cc: Atom Protocol In-Reply-To: <415037DA.9040309@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <415037DA.9040309@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Sep 2004 10:16:58 -0400, Robert Sayre wrote: > > http://intertwingly.net/wiki/pie/PaceIntrospection > http://intertwingly.net/wiki/pie/PaceCategoriesFacet > > These Paces detail the representation of resources termed "documents", > which seems a little circular to me. "Document" is the term used when descibing an XML format. If you have issues with that I suggest you take a careful look at the Atom Syndication Format, from which I borrowed such nomenclature. > What kind of resources are these? > Category Collections? Accounts? Domains? What's a "site"? You last question is a good one, currently being tackled by the Tag and in particular one of our co-chairs: http://www.tbray.org/ongoing/When/200x/2003/02/27/Websites http://www.tbray.org/ongoing/When/200x/2004/01/08/WebSite36 Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 07:44:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEil38037368 for ; Tue, 21 Sep 2004 07:44:47 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LEilp1037367 for atom-protocol-skb; Tue, 21 Sep 2004 07:44:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEikCn037357 for ; Tue, 21 Sep 2004 07:44:46 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9lsr-0000We-Oi; Tue, 21 Sep 2004 14:44:46 +0000 Message-ID: <41503E55.8000202@franklinmint.fm> Date: Tue, 21 Sep 2004 10:44:37 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Atom Protocol Subject: Re: Introspection and Category Documents References: <415037DA.9040309@franklinmint.fm> <3f1451f5040921074173266f27@mail.gmail.com> In-Reply-To: <3f1451f5040921074173266f27@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Joe Gregorio wrote: > On Tue, 21 Sep 2004 10:16:58 -0400, Robert Sayre wrote: > >>http://intertwingly.net/wiki/pie/PaceIntrospection >>http://intertwingly.net/wiki/pie/PaceCategoriesFacet >> >>These Paces detail the representation of resources termed "documents", >>which seems a little circular to me. > > > "Document" is the term used when descibing an XML > format. If you have issues with that I suggest you take > a careful look at the Atom Syndication Format, from > which I borrowed such nomenclature. I don't have any issue with the format or the term "document." I want to know what kind of resources these are. They look like Collections of categories and and Collections of Feeds to me. Robert Sayre From owner-atom-protocol Tue Sep 21 07:45:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEjjQU037428 for ; Tue, 21 Sep 2004 07:45:45 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LEjjNn037427 for atom-protocol-skb; Tue, 21 Sep 2004 07:45:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from [63.249.99.154] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LEjdJu037413; Tue, 21 Sep 2004 07:45:40 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3f1451f50409201745224a9ce5@mail.gmail.com> References: <3f1451f50409201745224a9ce5@mail.gmail.com> Date: Tue, 21 Sep 2004 07:45:42 -0700 To: Joe Gregorio , Atom Protocol From: Paul Hoffman / IMC Subject: Re: PaceCategoriesFacet Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:45 PM -0400 9/20/04, Joe Gregorio wrote: >3.4.2 Request > >The only method specified for this URI is GET. Wearing my naive, protocol-novice hat: why? Why shouldn't someone be able to update the list of categories from the protocol? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-protocol Tue Sep 21 08:11:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LFBmjE039743 for ; Tue, 21 Sep 2004 08:11:48 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LFBm8W039742 for atom-protocol-skb; Tue, 21 Sep 2004 08:11:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LFBlBV039731 for ; Tue, 21 Sep 2004 08:11:47 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4247590rnl for ; Tue, 21 Sep 2004 08:11:44 -0700 (PDT) Received: by 10.38.15.66 with SMTP id 66mr3017257rno; Tue, 21 Sep 2004 08:11:42 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 08:11:42 -0700 (PDT) Message-ID: <3f1451f504092108117ec3101a@mail.gmail.com> Date: Tue, 21 Sep 2004 11:11:42 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: mint@franklinmint.fm Subject: Re: Introspection and Category Documents Cc: Atom Protocol In-Reply-To: <41503E55.8000202@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <415037DA.9040309@franklinmint.fm> <3f1451f5040921074173266f27@mail.gmail.com> <41503E55.8000202@franklinmint.fm> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Sep 2004 10:44:37 -0400, Robert Sayre wrote: > > Joe Gregorio wrote: > > On Tue, 21 Sep 2004 10:16:58 -0400, Robert Sayre wrote: > > > >>http://intertwingly.net/wiki/pie/PaceIntrospection > >>http://intertwingly.net/wiki/pie/PaceCategoriesFacet > >> > >>These Paces detail the representation of resources termed "documents", > >>which seems a little circular to me. > > > > > > "Document" is the term used when descibing an XML > > format. If you have issues with that I suggest you take > > a careful look at the Atom Syndication Format, from > > which I borrowed such nomenclature. > > I don't have any issue with the format or the term "document." I want to > know what kind of resources these are. They look like Collections of > categories and and Collections of Feeds to me. PaceIntrospection is a collection of lists of of the parts of the Atom Protocol that each site supports. PaceCategoriesFacet is, as you observed, a collection of categories. -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 08:17:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LFHC9Y040508 for ; Tue, 21 Sep 2004 08:17:12 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LFHCYO040507 for atom-protocol-skb; Tue, 21 Sep 2004 08:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LFHCne040492 for ; Tue, 21 Sep 2004 08:17:12 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so4253494rnl for ; Tue, 21 Sep 2004 08:17:14 -0700 (PDT) Received: by 10.38.99.13 with SMTP id w13mr3756824rnb; Tue, 21 Sep 2004 08:17:14 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Tue, 21 Sep 2004 08:17:13 -0700 (PDT) Message-ID: <3f1451f504092108177f6f7c80@mail.gmail.com> Date: Tue, 21 Sep 2004 11:17:13 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Paul Hoffman / IMC Subject: Re: PaceCategoriesFacet Cc: Atom Protocol In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f50409201745224a9ce5@mail.gmail.com> Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 21 Sep 2004 07:45:42 -0700, Paul Hoffman / IMC wrote: > At 8:45 PM -0400 9/20/04, Joe Gregorio wrote: > >3.4.2 Request > > > >The only method specified for this URI is GET. > > Wearing my naive, protocol-novice hat: why? Why shouldn't someone be > able to update the list of categories from the protocol? It's the only method whose response is specified by this specification. No reason that some other spec, or a later version of this spec can't specify other methods. Note that this section, if adopted, will go into the protocol spec which contains the following verbage in Section 2: "There are three major classes of URIs in this specification: PostURI, FeedURI and EditURI. This specification defines the expected actions for each of the methods listed. A URI MAY support methods not listed here. For example, an EditURI could support a POST or OPTIONS method. However, what those methods do is beyond the scope of this specification." Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-protocol Tue Sep 21 09:32:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LGWdYu048677 for ; Tue, 21 Sep 2004 09:32:39 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LGWdrA048676 for atom-protocol-skb; Tue, 21 Sep 2004 09:32:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LGWcs1048662; Tue, 21 Sep 2004 09:32:38 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from [65.105.92.122] (helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9nZG-00034r-9N; Tue, 21 Sep 2004 16:32:38 +0000 Message-ID: <4150576C.1040708@franklinmint.fm> Date: Tue, 21 Sep 2004 12:31:40 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Joe Gregorio , Atom Protocol Subject: Re: PaceCategoriesFacet References: <3f1451f50409201745224a9ce5@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman / IMC wrote: > > At 8:45 PM -0400 9/20/04, Joe Gregorio wrote: > >> 3.4.2 Request >> >> The only method specified for this URI is GET. > > ...Why shouldn't someone be > able to update the list of categories from the protocol? Well, they should. The problem is that this resource is a representation of all the categories. It would be bad to update the entire list just to add, edit, or delete a single category. Here's an alternate serialization of Joe's concept (which I do think hits the 80/20 point for individual categories): http://www.example.com/mycategories/ My Categories HTTP/1.1 200 OK http://www.example.com/mycategories/books Category http://example.net/myontology/#books Books HTTP/1.1 200 OK http://www.example.com/mycategories/movies Category http://example.net/myontology/#movies Movies HTTP/1.1 200 OK http://www.example.com/mycategories/travel Category http://example.net/myontology/#travel Travel HTTP/1.1 200 OK The syntax of the atom:category properties isn't material. What is important is the mapping of an Atom representation to a list of properties. Some of which can be altered by the client, and some which can only be designated by the server. This representation would be returned by a GET request or, optionally, a PROPFIND request of depth: 1. Note that WebDAV (RFC2518) places no requirements on the representation returned by GET. It would also be possible to include a stylesheet PI with the GET, so the collection representation would be viewable in a browser (also true for Joe's proposal, but his would have no links). If you want to add a category, POST to the CategoryURI (http://example.com/mytcategories/). If you want to edit a category PUT an atom document with a category root element http://example.net/myontology/#travel Travel to one of the URIs you discovered in the representation of the category collection. To delete a category, DELETE to the uri of a particular category you discovered in the representation of the category collection. Thoughts? Robert Sayre From owner-atom-protocol Tue Sep 21 15:18:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LMICgj078834 for ; Tue, 21 Sep 2004 15:18:12 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LMICvB078833 for atom-protocol-skb; Tue, 21 Sep 2004 15:18:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LMIBXs078823 for ; Tue, 21 Sep 2004 15:18:11 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.2]) by web02.designerslab.net with asmtp (Exim 4.34) id 1C9sxe-0004zt-0p; Tue, 21 Sep 2004 22:18:10 +0000 Message-ID: <4150A8A3.3080809@franklinmint.fm> Date: Tue, 21 Sep 2004 18:18:11 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ezra Cooper CC: Atom Protocol Subject: Re: Template Constructs (was Re: ProtocolDataModel issues) References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <5D1603F1-084A-11D9-BC18-000A95CFF6CC@sixapart.com> <1f2ed5cd04091803206388b090@mail.gmail.com> <7704D093-0B60-11D9-82D6-000A95CFF6CC@sixapart.com> In-Reply-To: <7704D093-0B60-11D9-82D6-000A95CFF6CC@sixapart.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm X-Source: X-Source-Args: X-Source-Dir: Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ezra Cooper wrote: > > On Sep 18, 2004, at 3:20 AM, Danny Ayers wrote: > >> It would be useful to see these defined in a similar way to the model >> defined in the format spec. Could you give examples of how these would >> be used - what kind of transactions? > > > I posted PaceTemplateConstruct as a step in this direction. As to the > operations supported, only fetches and updates would be needed for > templates. From the pace: "Still open is the question of how a client can discover the set of templates stored by the Atom server." The critical issue here is metadata containment[0]. Everyone who has expressed an opinion on the issue agreed that templates need a MIME type, a name, and the blob of template content. I note that a server must understand the template MIME type do anything useful with it. Therefore, it's reasonable to assume that it could extract properties[1] from it. > > Assuming we have a good way to represent the templates themselves, > what's the best way for clients to discover them? If we have a resource > containing a list of the templates' URLs, then we could discover the URL > of that list from the contents at the FeedURI. Does that sound like a > reasonable use of the FeedURI? Sounds like a collection of templates. Note that the following syntax also supports a list of MIME types that the server supports for templates. It also allows us to use status code 415 (Unsupported Media Type) if a user tries to upload a Blogger template to a Movable Type site. Here's a representation of a template collection: http://www.example.com/mycategories/ My Templates TemplateCollection HTTP/1.1 200 OK http://www.example.com/mytemplates/index_page Template Index Page HTTP/1.1 200 OK http://www.example.com/mytemplates/monthly_archive Template Monthly Archive HTTP/1.1 200 OK http://www.example.com/mytemplates/Entry Template Entry HTTP/1.1 200 OK Thoughts? Robert Sayre [0] http://www.franklinmint.fm/blog/archives/000174.html [1] http://www.franklinmint.fm/blog/archives/000180.html From owner-atom-protocol Tue Sep 21 16:44:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LNiwQZ086384 for ; Tue, 21 Sep 2004 16:44:58 -0700 (PDT) (envelope-from owner-atom-protocol@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LNiwTn086383 for atom-protocol-skb; Tue, 21 Sep 2004 16:44:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-protocol@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LNivYY086375 for ; Tue, 21 Sep 2004 16:44:58 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id A0F9547BF8; Tue, 21 Sep 2004 16:43:29 -0700 (PDT) In-Reply-To: <4150A8A3.3080809@franklinmint.fm> References: <4142FEF1.3000006@franklinmint.fm> <1f2ed5cd04091109322b1d3a2a@mail.gmail.com> <414338E0.2020106@franklinmint.fm> <8D68EE31-05C1-11D9-9A95-000A95CFF6CC@sixapart.com> <4147666B.6010501@franklinmint.fm> <3f1451f504091511101115c5df@mail.gmail.com> <20040915182337.GC9997@google.com> <5B97EE3E-0785-11D9-854B-000A95A51C9E@sun.com> <5D1603F1-084A-11D9-BC18-000A95CFF6CC@sixapart.com> <1f2ed5cd04091803206388b090@mail.gmail.com> <7704D093-0B60-11D9-82D6-000A95CFF6CC@sixapart.com> <4150A8A3.3080809@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55380360-0C28-11D9-82D6-000A95CFF6CC@sixapart.com> Content-Transfer-Encoding: 7bit Cc: Atom Protocol From: Ezra Cooper Subject: Template Facet (was Re: Template Constructs) Date: Tue, 21 Sep 2004 16:45:35 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.619) Sender: owner-atom-protocol@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Robert, I'm not sure I understand which problem you're trying to solve here. Are you proposing syntax for a template list? Are you proposing to layer the template-editing protocol on WebDAV in this respect? My thinking is that we'd discover the templates in a manner parallel to the category discovery/manipulation. Working from the syntax of PaceCategoriesFacet, the introspection file would have a service element for the template facet: Then, at http://example.org/reilly/templates, we'd have some kind of template list: