From owner-atom-syntax@mail.imc.org Wed Jun 30 11:31:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24171 for ; Wed, 30 Jun 2004 11:31:44 -0400 (EDT) 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 i5UFBNTp006317; Wed, 30 Jun 2004 08:11:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFBNGJ006316; Wed, 30 Jun 2004 08:11:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [212.123.84.92]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFBI1O006300 for ; Wed, 30 Jun 2004 08:11:23 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from virgilio.it (62.11.125.181) by mail-relay-2.tiscali.it (7.1.021.3) id 40D9B22D0027B747; Wed, 30 Jun 2004 17:11:13 +0200 Message-ID: <40E2D7AD.3070404@virgilio.it> Date: Wed, 30 Jun 2004 17:09:33 +0200 From: Danny Ayers Reply-To: danny666@virgilio.it User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken MacLeod CC: atom syntax list Subject: Re: PaceIntrospection: Is another file format really needed? References: <40DC2066.1070100@spoonybards.net> <40DF403D.5050808@spoonybards.net> <1C98E8B4-C928-11D8-B7C2-000A95B09B46@google.com> <40E1A28B.6090302@aol.com> <40E1EFFB.4090602@spoonybards.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ken MacLeod wrote: > To me, atom:feed is a syndication feed. Extending it to an >index/archive format has shown its weaknesses for general tasks (which >feed headers are the "main" ones? why do the rest need all the >required elements when they could point to a site or category origin?) > > Yep. Overloading atom:feed would only add to confusion, it's already got a lot of potential for confusion when people are used to seeing more static documents. >Entries are being forced to be both log entries and metadata wrappers, >and they're pretty oddly defined metadata wrappers. > > I like the idea of an entry being comparable to media that carries embedded metadata. There's some structural stuff in the file, there's the content and there's the metadata about the content. Given that we're using XML on the web it does make it easier to point to non-embedded things (even the content), but I think the general idea of atom:entry as content+metadata parcels works well. If other parcels are needed for introspection of whatever then I think something other than atom:entry would be more appropriate. >>Once again, it's all a matter of doing the simplest thing that could >>possibly work. >> >> > >There are two parts to the DTSTTCPW rule: 1) implement a new >capability in the simplest, then 2) refactor. [1] > >You don't get a chance to refactor much after you've published a >public format or protocol. DTSTTCPW only applies during the iterative >development phase before final release. This is why we must pay >attention to long term use and extension. > > Right, thanks for saying that, it bugs me like talk of YAGNI here has done before - these development patterns work for implementations, but not necessarily specifications. Different game, different rules. Cheers, Danny. -- Raw http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jun 30 11:59:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25960 for ; Wed, 30 Jun 2004 11:59:17 -0400 (EDT) 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 i5UFh27V009837; Wed, 30 Jun 2004 08:43:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFh2Ga009836; Wed, 30 Jun 2004 08:43:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFh2vS009775 for ; Wed, 30 Jun 2004 08:43:02 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (sccrmhc13) with SMTP id <200406301542590160029qhae>; Wed, 30 Jun 2004 15:42:59 +0000 Date: Wed, 30 Jun 2004 09:42:58 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PacePersonRef posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <2932EE92-CAAC-11D8-B980-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Since I saw no objections to my email of a few days ago, I've posted PacePersonRef http://www.intertwingly.net/wiki/pie/PacePersonRef Here's the core of it: * Abstract This proposal defines a method for creating person constructs at the feed level (which do not apply directly to the feed as a whole) and then referring to them from the feed level or within entries. Because referring to an author can be done compactly, inheritance by entries that don't specify an author of the feed:author is removed. * Rationale In most feeds, the author is the same for many, if not all, entries, leading to repetition of author metadata. This can be avoided by specifying the metadata in one place in the feed and referring to it from other parts of the feed. Also, at a conceptual level, while identification of the author and contributor(s) is part of an entry, their metadata isn't necessarily part of an entry. Thus it may be logically preferable to specify that metadata outside of the entry itself. * Proposal Insert the following before section 4.5 atom:author of the Atom format specification: 4.5 atom:people Element The "atom:people" element is a container for atom:person elements. It MAY contain any number of atom:person elements. 4.5.1 atom:person Element The "atom:person" element is a Person construct, and MUST follow all requirements for Person constructs. Additionally, it MUST have an id attribute. 4.5.1.1 id Attribute The atom:person element's id attribute is a string. It may contain any string which does not appear in the id attribute of any other atom:person within the feed as it is served at a particular time. It is NOT REQUIRED to be unique across feeds, and the id associated with a particular Person MAY change. The same id MAY be used for a different Person construct each time the feed is served. Remove "[[explain inheritance]]" from section 4.5. Replace section 4.13.3 with the following: 4.13.3 "atom:author" Element The "atom:author" element is a Person construct that indicates the primary author of the entry. atom:entry MAY contain one atom:author element, but MUST NOT contain more than one. If it does not contain an atom:author element, then the author of the entry MUST be considered unknown or anonymous. It is not inherited from the feed. Insert the following under section 3.2 Person Contructs: 3.2.1 "rel" attribute The "rel" attribute associates a Person construct with an atom:person element appearing inside the atom:people element. If a Person constuct has a rel attribute, it MUST NOT have any child elements. Instead, their values are taken from the atom:person whose id attribute matches the rel attribute. From owner-atom-syntax@mail.imc.org Wed Jun 30 11:59:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25998 for ; Wed, 30 Jun 2004 11:59:21 -0400 (EDT) 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 i5UFkvHa010528; Wed, 30 Jun 2004 08:46:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFkvsA010527; Wed, 30 Jun 2004 08:46:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01-ext.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFkuXU010511 for ; Wed, 30 Jun 2004 08:46:57 -0700 (PDT) (envelope-from dorchard@bea.com) Received: from ussjfe01.amer.bea.com (ussjfe01b.bea.com [172.16.120.57]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i5UFiO8j001715; Wed, 30 Jun 2004 08:46:56 -0700 Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jun 2004 08:40:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AtomPubIssuesList Date: Wed, 30 Jun 2004 08:40:27 -0700 Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08A31CF2@ussjex01.amer.bea.com> Thread-Topic: AtomPubIssuesList Thread-Index: AcRYYA2ii6aZPWDpS86kzzHOzZBasgGVwQHw From: "David Orchard" To: "Sam Ruby" , "Atom-Syntax Syntax" X-OriginalArrivalTime: 30 Jun 2004 15:40:27.0976 (UTC) FILETIME=[91689480:01C45EB8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5UFkvXU010521 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org > [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Sam Ruby > Sent: Tuesday, June 22, 2004 6:50 AM > To: Atom-Syntax Syntax > Subject: AtomPubIssuesList > > I note a lack of a proposal for getting extensibility points > right, with > MustUnderstand and MustIgnore and so on. Until or unless there is a > concrete proposal, such issues will not be tracked. > I think I was asked to look into this, and accepted the action item. I spoke with Tim Bray last week, and he assured me that this was not a high priority item, especially when I mentioned I was looking at what Atom would look like in WSDL 2.0 and WSDL 2.0 has hopefully a strong HTTP binding. Is this wrong? I would have thought that you: - would have an "extensibility" action item outstanding - would check with the action item owner periodically - would have an open issue with an issue raiser and the assigned action item. The only issue I see related is the PaceEntryElementNeedsVersionAttribute. Cheers, Dave From owner-atom-syntax@mail.imc.org Wed Jun 30 12:03:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26197 for ; Wed, 30 Jun 2004 12:03:00 -0400 (EDT) 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 i5UFiI1J010056; Wed, 30 Jun 2004 08:44:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFiID8010055; Wed, 30 Jun 2004 08:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFiHB8010034 for ; Wed, 30 Jun 2004 08:44:17 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [67.119.69.246] (adsl-67-119-69-246.dsl.sntc01.pacbell.net [67.119.69.246]) by mail.mnot.net (Postfix) with ESMTP id 84E80727D; Wed, 30 Jun 2004 08:44:20 -0700 (PDT) In-Reply-To: <40E27354.9000804@dehora.net> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> Cc: atom-syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PacePutIpAddrInEntry Date: Wed, 30 Jun 2004 08:44:20 -0700 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5UFiHB8010041 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jun 30, 2004, at 1:01 AM, Bill de hÓra wrote: > >> -1. > > To what? - atom:ipaddr in the format -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 30 13:03:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29281 for ; Wed, 30 Jun 2004 13:03:53 -0400 (EDT) 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 i5UGjouN015171; Wed, 30 Jun 2004 09:45:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UGjoOO015170; Wed, 30 Jun 2004 09:45:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UGjnWK015164 for ; Wed, 30 Jun 2004 09:45:49 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (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 i5UGk1Vg001739; Wed, 30 Jun 2004 12:46:02 -0400 Message-ID: <40E2EE3E.2030200@intertwingly.net> Date: Wed, 30 Jun 2004 12:45:50 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: atom-syntax Subject: Re: PacePutIpAddrInEntry References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> In-Reply-To: <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark Nottingham wrote: > > > On Jun 30, 2004, at 1:01 AM, Bill de hÓra wrote: > >>> -1. >> >> To what? > > - atom:ipaddr in the format Quoting from the charter: """Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content.""" I would assert that an ip address would qualify as "basic, generic metadata" for Wikis. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jun 30 13:20:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29945 for ; Wed, 30 Jun 2004 13:20:07 -0400 (EDT) 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 i5UH7C6K016977; Wed, 30 Jun 2004 10:07:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UH7CK7016976; Wed, 30 Jun 2004 10:07:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UH7CqJ016970 for ; Wed, 30 Jun 2004 10:07:12 -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 1BfiY8-0006z8-Sc; Wed, 30 Jun 2004 17:07:09 +0000 Message-ID: <40E2F338.4080100@franklinmint.fm> Date: Wed, 30 Jun 2004 13:07:04 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Mark Nottingham , atom-syntax Subject: Re: PacePutIpAddrInEntry References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> In-Reply-To: <40E2EE3E.2030200@intertwingly.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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Quoting from the charter: > > """Atom defines a feed format for representing and a protocol for > editing Web resources such as Weblogs, online journals, Wikis, and > similar content.""" > > I would assert that an ip address would qualify as "basic, generic > metadata" for Wikis. > Shouldn't elements defined in the core format spec be applicable to every item in that list? I think a case could be made that IP is, but Wikis alone is not sufficient. My journal could really use atom:mood. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jun 30 13:20:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00004 for ; Wed, 30 Jun 2004 13:20:31 -0400 (EDT) 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 i5UH9X6a017566; Wed, 30 Jun 2004 10:09:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UH9XhU017565; Wed, 30 Jun 2004 10:09:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UH9WsR017559 for ; Wed, 30 Jun 2004 10:09:32 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [67.119.69.246] (adsl-67-119-69-246.dsl.sntc01.pacbell.net [67.119.69.246]) by mail.mnot.net (Postfix) with ESMTP id 08CA8727D; Wed, 30 Jun 2004 10:09:36 -0700 (PDT) In-Reply-To: <40E2EE3E.2030200@intertwingly.net> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PacePutIpAddrInEntry Date: Wed, 30 Jun 2004 10:08:35 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 30, 2004, at 9:45 AM, Sam Ruby wrote: > I would assert that an ip address would qualify as "basic, generic > metadata" for Wikis. Fair enough. It still encourages reading things into IP addresses that shouldn't be read into them, and is bad practice. It's akin to counters on Web pages; some people think they're useful and gleefully put them on every page, when in fact they have a very doubtful relationship to reality [1]. That's not to say that people shouldn't be allowed to use either mechanism, just that they shouldn't be baked into an IETF standards-track document. 1. http://www.goldmark.org/netrants/webstats/ -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 30 13:24:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00123 for ; Wed, 30 Jun 2004 13:24:14 -0400 (EDT) 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 i5UGtKr9015730; Wed, 30 Jun 2004 09:55:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UGtKAj015729; Wed, 30 Jun 2004 09:55:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UGtJtr015722 for ; Wed, 30 Jun 2004 09:55:19 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i5UGtA53013840; Wed, 30 Jun 2004 11:55:11 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i5UGtAfU013836; Wed, 30 Jun 2004 11:55:10 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: "Atom-Syntax Syntax" Cc: "David Orchard" Subject: Re: AtomPubIssuesList References: <32D5845A745BFB429CBDBADA57CD41AF08A31CF2@ussjex01.amer.bea.com> From: Ken MacLeod Date: 30 Jun 2004 11:55:10 -0500 In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08A31CF2@ussjex01.amer.bea.com> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "David Orchard" writes: > [Sam Ruby wrote:] > > > > I note a lack of a proposal for getting extensibility points > > right, with MustUnderstand and MustIgnore and so on. Until or > > unless there is a concrete proposal, such issues will not be > > tracked. > > I think I was asked to look into this, and accepted the action item. > I spoke with Tim Bray last week, and he assured me that this was not > a high priority item, especially when I mentioned I was looking at > what Atom would look like in WSDL 2.0 and WSDL 2.0 has hopefully a > strong HTTP binding. Is this wrong? > > I would have thought that you: > - would have an "extensibility" action item outstanding > - would check with the action item owner periodically > - would have an open issue with an issue raiser and the assigned > action item. > > The only issue I see related is the > PaceEntryElementNeedsVersionAttribute. One format extensibility issue that is currently on a lot of people's minds is the "link construct", in PaceLinkConstruct, recently summarized by Robert Sayre, http://imc.org/atom-syntax/mail-archive/msg06039.html and with a noticable post by none other than yourself back in December, http://imc.org/atom-syntax/mail-archive/msg01726.html The "link construct" issue is a current permathread. My take on it is, "wait until PaceLinkConstruct comes to the top of the queue, and for now let's focus on model instead of markup". What would be good to know from an extensibility perspective is if you will be looking at this issue specifically while it's waiting to come to the top of the queue, and may have a proposal by then, or should others be working on it in the background. -- Ken From owner-atom-syntax@mail.imc.org Wed Jun 30 14:07:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02439 for ; Wed, 30 Jun 2004 14:07:14 -0400 (EDT) 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 i5UHgLG3020227; Wed, 30 Jun 2004 10:42:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UHgLHP020226; Wed, 30 Jun 2004 10:42:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UHgInd020219; Wed, 30 Jun 2004 10:42:19 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> Date: Wed, 30 Jun 2004 10:42:19 -0700 To: Mark Nottingham , Sam Ruby From: Paul Hoffman / IMC Subject: Re: PacePutIpAddrInEntry Cc: atom-syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:08 AM -0700 6/30/04, Mark Nottingham wrote: >It still encourages reading things into IP addresses that shouldn't >be read into them, and is bad practice. ...which is completely widespread in the IETF. The IETF has been grappling with this for over five years, and has made nearly no headway at all. So, it's safe for us to treat IP addresses like other identifiers for now. >That's not to say that people shouldn't be allowed to use either >mechanism, just that they shouldn't be baked into an IETF >standards-track document. Dream on. :-) We have IP-addresses-as-identifiers baked into everything from PKIX to IPsec to you-name-it. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Jun 30 14:20:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03067 for ; Wed, 30 Jun 2004 14:20:40 -0400 (EDT) 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 i5UI0uJ7021937; Wed, 30 Jun 2004 11:00:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UI0uMG021936; Wed, 30 Jun 2004 11:00:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UI0tUe021930 for ; Wed, 30 Jun 2004 11:00:55 -0700 (PDT) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BfjOD-0000V8-00; Wed, 30 Jun 2004 20:00:57 +0200 Received: from [62.155.220.138] (helo=baron) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BfjOD-0004FD-00; Wed, 30 Jun 2004 20:00:57 +0200 Message-ID: <002d01c45ecc$472eb840$8adc9b3e@baron> From: "Andreas Sewe" To: "Antone Roundy" Cc: "[Atom]" References: <2932EE92-CAAC-11D8-B980-003065EA6144@geckotribe.com> Subject: Re: PacePersonRef posted Date: Wed, 30 Jun 2004 20:01:24 +0200 Organization: Fachbereich Informatik, TU Darmstadt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > 3.2.1 "rel" attribute > The "rel" attribute associates a Person construct with an atom:person > element appearing inside the atom:people element. If a Person constuct > has a rel attribute, it MUST NOT have any child elements. Instead, > their values are taken from the atom:person whose id attribute matches > the rel attribute. Shouldn't this be @ref instead of @rel, which is used in different contexts too? You suggested this yourself some days ago: > This looks like a good time to re-raise an idea I mentioned in May in > reference to copyright information [1]. It got one positive response, > and no other mention (and no, I didn't create a Pace...if the idea > doesn't get thoroughly shot down, I will). Here's a super-simplified > feed using @id and @ref to minimize data duplication: Besides that the proposal looks fine to me. Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Wed Jun 30 14:21:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03103 for ; Wed, 30 Jun 2004 14:21:01 -0400 (EDT) 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 i5UI6mWo022285; Wed, 30 Jun 2004 11:06:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UI6mf2022284; Wed, 30 Jun 2004 11:06:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UI6mhf022277 for ; Wed, 30 Jun 2004 11:06:48 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc12) with SMTP id <2004063018064601400ic303e>; Wed, 30 Jun 2004 18:06:46 +0000 Date: Wed, 30 Jun 2004 12:06:44 -0600 Subject: Re: PacePersonRef posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <002d01c45ecc$472eb840$8adc9b3e@baron> Message-Id: <3F2D0CBE-CAC0-11D8-B980-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, June 30, 2004, at 12:01 PM, Andreas Sewe wrote: > Antone Roundy wrote: >> 3.2.1 "rel" attribute > >> The "rel" attribute associates a Person construct with an atom:person >> element appearing inside the atom:people element. If a Person constuct >> has a rel attribute, it MUST NOT have any child elements. Instead, >> their values are taken from the atom:person whose id attribute matches >> the rel attribute. > > Shouldn't this be @ref instead of @rel Yeah, I noticed that just after sending the email out and have fixed it on the wiki. From owner-atom-syntax@mail.imc.org Wed Jun 30 14:30:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03721 for ; Wed, 30 Jun 2004 14:30:06 -0400 (EDT) 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 i5UIDDRP022628; Wed, 30 Jun 2004 11:13:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIDDqa022627; Wed, 30 Jun 2004 11:13:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UIDDSI022614; Wed, 30 Jun 2004 11:13:13 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [67.119.69.246] (adsl-67-119-69-246.dsl.sntc01.pacbell.net [67.119.69.246]) by mail.mnot.net (Postfix) with ESMTP id EE4BB727D; Wed, 30 Jun 2004 11:13:16 -0700 (PDT) In-Reply-To: References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax , Sam Ruby X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PacePutIpAddrInEntry Date: Wed, 30 Jun 2004 11:12:16 -0700 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 30, 2004, at 10:42 AM, Paul Hoffman / IMC wrote: > Dream on. :-) We have IP-addresses-as-identifiers baked into > everything from PKIX to IPsec to you-name-it. Come on, Paul; there's a huge difference between baking it into the context for purposes of security and exposing it to end-users in an application protocol as a means of uniquely identifying a person, especially when the substrate - HTTP - actively disassociates IP addresses from user agetns. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 30 14:35:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04369 for ; Wed, 30 Jun 2004 14:35:35 -0400 (EDT) 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 i5UIMfqv023232; Wed, 30 Jun 2004 11:22:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIMfoL023231; Wed, 30 Jun 2004 11:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UIMeiL023214 for ; Wed, 30 Jun 2004 11:22:40 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 0675B7C0F3; Wed, 30 Jun 2004 21:19:10 +0200 (CEST) To: "Andreas Sewe" Cc: Atom-Syntax Subject: Re: Proposal: PaceSyntaxGuidelines References: <014801c45eae$6c237500$90d9e03e@baron> Message-ID: Date: Wed, 30 Jun 2004 20:25:38 +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: <014801c45eae$6c237500$90d9e03e@baron> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 16:27:42 +0200, Andreas Sewe wrote: > since you are probably the one most concernd about the consistency of > Atom's syntax (or at least the one most active in this area), you're > perhaps interested in a short list I've compiled a while ago, > summarizing the different syntactic guidelines followed by various XML > vocabularies. Thanks, that was a good summary. In basic, I want Atom to follow the same guidlines as XSLT, because I find that a _very_ intuitive, consistent and beautiful language. I'm not against camelCase or PascalCase, but we should be consistent, not only with naming syntax, but also in what we use attributes and elements for. > So, do whatever you like with this list, I just hope it's somewhat useful It was somewhat useful, and very clarifying. Nice to have it black on white like that. > At any rate, it's good work you Atom guys do. You don't consider yourself an Atom guy? If so, why not? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 14:36:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04422 for ; Wed, 30 Jun 2004 14:36:03 -0400 (EDT) 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 i5UIN6X3023262; Wed, 30 Jun 2004 11:23:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIN6O5023261; Wed, 30 Jun 2004 11:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UIN4XQ023254; Wed, 30 Jun 2004 11:23:04 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> Date: Wed, 30 Jun 2004 11:23:06 -0700 To: Mark Nottingham From: Paul Hoffman / IMC Subject: Re: PacePutIpAddrInEntry Cc: atom-syntax , Sam Ruby Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:12 AM -0700 6/30/04, Mark Nottingham wrote: >On Jun 30, 2004, at 10:42 AM, Paul Hoffman / IMC wrote: > >>Dream on. :-) We have IP-addresses-as-identifiers baked into >>everything from PKIX to IPsec to you-name-it. > >Come on, Paul; there's a huge difference between baking it into the >context for purposes of security and exposing it to end-users in an >application protocol as a means of uniquely identifying a person, >especially when the substrate - HTTP - actively disassociates IP >addresses from user agetns. I'm not talking about IP addresses identifying humans (although that is done too), but as ways of identifying machines. There are many contexts where a machine, not a person, is the creator of an entry. I'm hoping Atom gets used for feeds of status alerts from hosts, for example. In that case, an IP address or a DNS name are reasonable identifiers. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Jun 30 14:55:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05900 for ; Wed, 30 Jun 2004 14:55:30 -0400 (EDT) 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 i5UIdYBv025028; Wed, 30 Jun 2004 11:39:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIdYxp025024; Wed, 30 Jun 2004 11:39:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UIdXQE024896 for ; Wed, 30 Jun 2004 11:39:33 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 72B597C112; Wed, 30 Jun 2004 21:36:10 +0200 (CEST) Date: Wed, 30 Jun 2004 20:42:42 +0200 To: "Sam Ruby" Subject: Re: PacePutIpAddrInEntry Cc: Atom-Syntax References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> 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: <40E2EE3E.2030200@intertwingly.net> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 12:45:50 -0400, Sam Ruby wrote: > I would assert that an ip address would qualify as "basic, generic > metadata" for Wikis. I have nothing against having an element or @rel that binds an IP address to the originator of a feed or entry (we should look into if this could be the IP address of a web server, in terms for pingbacks, trackbacks etc), but as the syntax nazi I am, I think it looks neater with . Only four extra characters, but easier to read and prettier than . E.g. I see no reason to shorten an already as short word as 'ip-address'. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 14:57:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06272 for ; Wed, 30 Jun 2004 14:57:01 -0400 (EDT) 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 i5UIeOtE025221; Wed, 30 Jun 2004 11:40:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIeN3Z025220; Wed, 30 Jun 2004 11:40:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UIeNnN025214 for ; Wed, 30 Jun 2004 11:40:23 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from intertwingly.net (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 i5UIecw0008082 for ; Wed, 30 Jun 2004 14:40:39 -0400 Message-ID: <40E3091B.8060202@intertwingly.net> Date: Wed, 30 Jun 2004 14:40:27 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: PacePutIpAddrInEntry References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> In-Reply-To: <40E2F338.4080100@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > Sam Ruby wrote: > >> Quoting from the charter: >> >> """Atom defines a feed format for representing and a protocol for >> editing Web resources such as Weblogs, online journals, Wikis, and >> similar content.""" >> >> I would assert that an ip address would qualify as "basic, generic >> metadata" for Wikis. > > Shouldn't elements defined in the core format spec be applicable to > every item in that list? I think a case could be made that IP is, but > Wikis alone is not sufficient. My journal could really use atom:mood. I track and publish[1] IP addresses on my weblog. It has cut down significantly on "spoofing". I discussed a case[2] recently where somebody "anonymously" updated the wiki. Somebody proporting to be Bill de hÓra stepped forward and claimed responsibility. Truth be told, I personally trust the ip addresses information more than the SMTP headers. - Sam Ruby [1] http://www.intertwingly.net/blog/comments.atom [2] http://www.imc.org/atom-syntax/mail-archive/msg05871.html From owner-atom-syntax@mail.imc.org Wed Jun 30 15:06:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07212 for ; Wed, 30 Jun 2004 15:06:53 -0400 (EDT) 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 i5UIt8dK026640; Wed, 30 Jun 2004 11:55:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIt88a026639; Wed, 30 Jun 2004 11:55:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UIt64J026630 for ; Wed, 30 Jun 2004 11:55:07 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 0B90E7C0F3; Wed, 30 Jun 2004 21:51:44 +0200 (CEST) To: danny666@virgilio.it Cc: Atom-Syntax Subject: Re: PaceIntrospection: Is another file format really needed? References: <40DC2066.1070100@spoonybards.net> <40DF403D.5050808@spoonybards.net> <1C98E8B4-C928-11D8-B7C2-000A95B09B46@google.com> <40E1A28B.6090302@aol.com> <40E1EFFB.4090602@spoonybards.net> <40E2D7AD.3070404@virgilio.it> Message-ID: Date: Wed, 30 Jun 2004 20:58:20 +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: <40E2D7AD.3070404@virgilio.it> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 17:09:33 +0200, Danny Ayers wrote: > I think the general idea of atom:entry as content+metadata parcels works > well. +1. > If other parcels are needed for introspection of whatever then I think > something other than atom:entry would be more appropriate. +1. Different purposes, different elements, models and constructs. There's no real point in reusing atom:feed and atom:entry if what we're trying to do with them is totally different from the element's original purpose. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 15:24:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08851 for ; Wed, 30 Jun 2004 15:24:36 -0400 (EDT) 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 i5UIp678026406; Wed, 30 Jun 2004 11:51:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UIp60M026405; Wed, 30 Jun 2004 11:51:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UIp5hh026387 for ; Wed, 30 Jun 2004 11:51:06 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id CF7DF7C0F3; Wed, 30 Jun 2004 21:47:42 +0200 (CEST) Date: Wed, 30 Jun 2004 20:54:18 +0200 To: =?iso-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: author tag References: <14be96d304062419086ec02b78@mail.gmail.com> <40DEB5B1.1000302@intertwingly.net> <1C8301E6-C858-11D8-A9BF-000A95BD86C0@mnot.net> <40DF1957.1070901@bitworking.org> <40DF25CE.7020006@virgilio.it> <20040628135044.GI11231@google.com> <40E027C5.3050100@dehora.net> <40E05FEF.4020209@dehora.net> Cc: Atom-Syntax 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: <40E05FEF.4020209@dehora.net> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 28 Jun 2004 19:14:07 +0100, Bill de hÓra wrote: >> The current draft is missing some explanation on the author >> inheritance from atom:feed to atom:entry, > > Perhaps that because it's complicated ;) I agree it's complicated. Maybe PacePersonRef[1] is a simpler solution? I think I remember discussing this a year ago or something, but have no idea of what came out of that discussion. When I look at it now, I think it's probably simpler than the value-inheritance from feed to entry. Inherited values works fine if the construct is implicitly or explicitly required. Now that we've discovered that Atom probably should be possible to use anonymously, author can't be required anymore. That causes trouble with the inheritance, since the inherited value from feed must be overriden to a blank one if the entry is posted anonymously. > Why not just markup the information explicitly? The less of a processing > model we require around the Atom format the more useful it will be Of course, but duplicating (and possibly other Author Construct) elements in a feed with 100 entries is not very cool. I think PacePersonRef might be a feasible solution to having optional authors. Maybe we could even add an @href and @type attribute on the element and have it link to a FOAF file somewhere. >> Should we at least require someone to take authorship and >> responsibility for the feed? > > There's perhaps no need. At a web arch level it's implied by the feed > URIs. I don't think an URI implies authorship. The feed might be syntethic, and all sorts of other things. This _might_ be fixed by , but there's a lot of other issues I can't think of right now that we need to cover. ____ [1] -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 15:39:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09692 for ; Wed, 30 Jun 2004 15:39:51 -0400 (EDT) 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 i5UINWO1023291; Wed, 30 Jun 2004 11:23:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UINW2j023290; Wed, 30 Jun 2004 11:23:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UINVXw023271 for ; Wed, 30 Jun 2004 11:23:32 -0700 (PDT) (envelope-from ken@bitsko.slc.ut.us) Received: from localhost.localdomain (tara [127.0.0.1]) by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i5UINU53015581 for ; Wed, 30 Jun 2004 13:23:30 -0500 Received: (from ken@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i5UINTJQ015577; Wed, 30 Jun 2004 13:23:29 -0500 X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f To: atom-syntax@imc.org Subject: Comparing Atom and WebDAV From: Ken MacLeod Date: 30 Jun 2004 13:23:29 -0500 Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've posted an article on my weblog, with a corresponding publicly updateable version on the wiki, that compares the facilities in Atom and WebDAV: http://bitsko.slc.ut.us/blog/atom-webdav.html http://intertwingly.net/wiki/pie/WebDavVsAtom This article does not make any proposals. It provides background and comparitive information that may help in focusing Atom efforts where they need to be. The last two sections on "Atom-enabling a WebDAV publishing system" and "defining Atom as a conformant profile of WebDAV" compares the two by implementing one in the other -- a WebDAV system using Atom and a definition of Atom based on WebDAV. -- Ken From owner-atom-syntax@mail.imc.org Wed Jun 30 15:48:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10244 for ; Wed, 30 Jun 2004 15:48:52 -0400 (EDT) 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 i5UJYgAY029765; Wed, 30 Jun 2004 12:34:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UJYg64029764; Wed, 30 Jun 2004 12:34:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UJYgWf029733; Wed, 30 Jun 2004 12:34:42 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [67.119.69.246] (adsl-67-119-69-246.dsl.sntc01.pacbell.net [67.119.69.246]) by mail.mnot.net (Postfix) with ESMTP id 506DA727D; Wed, 30 Jun 2004 12:34:46 -0700 (PDT) In-Reply-To: References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89E6011F-CACC-11D8-B7F4-000A95BD86C0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax , Sam Ruby X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PacePutIpAddrInEntry Date: Wed, 30 Jun 2004 12:34:44 -0700 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 30, 2004, at 11:23 AM, Paul Hoffman / IMC wrote: > I'm hoping Atom gets used for feeds of status alerts from hosts, for > example. In that case, an IP address or a DNS name are reasonable > identifiers. That sounds like a great use case for an Atom extension, but it's completely outside of our charter to include such a mechanism in the core protocol. I'm hoping to use Atom to carry stock tickers; should we bake metadata for that into the Atom format? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 30 15:55:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10797 for ; Wed, 30 Jun 2004 15:55:09 -0400 (EDT) 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 i5UJfrEo030153; Wed, 30 Jun 2004 12:41:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UJfrBu030152; Wed, 30 Jun 2004 12:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UJfq8H030146 for ; Wed, 30 Jun 2004 12:41:52 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [67.119.69.246] (adsl-67-119-69-246.dsl.sntc01.pacbell.net [67.119.69.246]) by mail.mnot.net (Postfix) with ESMTP id E39ED727D; Wed, 30 Jun 2004 12:41:56 -0700 (PDT) In-Reply-To: <40E3091B.8060202@intertwingly.net> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net> Cc: atom-syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PacePutIpAddrInEntry Date: Wed, 30 Jun 2004 12:41:56 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5UJfq8H030147 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jun 30, 2004, at 11:40 AM, Sam Ruby wrote: > I track and publish[1] IP addresses on my weblog. It has cut down > significantly on "spoofing". Great. Why is it necessary to standardise it? Why does it have to be captured in an Atom feed in a way that's interoperable between implementations? > I discussed a case[2] recently where somebody "anonymously" updated > the wiki. Somebody proporting to be Bill de hÓra stepped forward and > claimed responsibility. Truth be told, I personally trust the ip > addresses information more than the SMTP headers. Same as above. Using IP addresses in your system is different to codifying their use in formats and protocols. Put it this way; would you trust an field in a post that someone made to your blog over the IP address that your system thinks they're coming from? Both can be spoofed, but I think you'll agree it's technically easier to spoof the XML. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 30 16:06:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11871 for ; Wed, 30 Jun 2004 16:06:44 -0400 (EDT) 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 i5UJpi2o030959; Wed, 30 Jun 2004 12:51:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UJpiT1030958; Wed, 30 Jun 2004 12:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail4.edisontel.com ([62.94.0.37]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UJph99030935 for ; Wed, 30 Jun 2004 12:51:44 -0700 (PDT) (envelope-from danny666@virgilio.it) Received: from virgilio.it (62.94.14.180) by mail4.edisontel.com (7.0.024) id 3FB4847C008B9D12; Wed, 30 Jun 2004 21:51:15 +0200 Message-ID: <40E3194F.1070803@virgilio.it> Date: Wed, 30 Jun 2004 21:49:35 +0200 From: Danny Ayers Reply-To: danny666@virgilio.it User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken MacLeod CC: Atom-Syntax Syntax , David Orchard Subject: Re: AtomPubIssuesList References: <32D5845A745BFB429CBDBADA57CD41AF08A31CF2@ussjex01.amer.bea.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ken MacLeod wrote: >>I think I was asked to look into this, and accepted the action item. >>I spoke with Tim Bray last week, and he assured me that this was not >>a high priority item, especially when I mentioned I was looking at >>what Atom would look like in WSDL 2.0 and WSDL 2.0 has hopefully a >>strong HTTP binding. Is this wrong? >> >> Personally I believe extensibility to be one of the highest priorities. As Ken says, to date most of the suggestions relating to this have focussed on the link element (e.g. PaceLinkRelMechanism). However this I think has been with the general tacit assumption that the addition of extensions as elements/attributes in other namespaces would (somehow) serve the purpose. It may well, but I believe it is in the interests of the project to define constraints and if possible common interpretation of this, along the lines of RDF/XML or the (now rather dusty) ExtensibilityFramework proposed on the Wiki. [snip] >My take on it is, "wait until PaceLinkConstruct comes to the top of >the queue, and for now let's focus on model instead of markup". What >would be good to know from an extensibility perspective is if you will >be looking at this issue specifically while it's waiting to come to >the top of the queue, and may have a proposal by then, or should >others be working on it in the background. > > Yep, that sounds good. btw, Randy's been working on Atom in WSDL: http://www.kbcafe.com/iBLOGthere4iM/?guid=20040609151444 Cheers, Danny. -- Raw http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Jun 30 16:09:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12259 for ; Wed, 30 Jun 2004 16:09:33 -0400 (EDT) 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 i5UJsF8a031235; Wed, 30 Jun 2004 12:54:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UJsFHA031234; Wed, 30 Jun 2004 12:54:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5UJsEW4031217 for ; Wed, 30 Jun 2004 12:54:14 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 8109 messnum 15290826 invoked from network[83.70.35.17/83-70-35-17.bas2.prp.dublin.eircom.net]); 30 Jun 2004 19:54:13 -0000 Received: from 83-70-35-17.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.35.17) by mail11.svc.cra.dublin.eircom.net (qp 8109) with SMTP; 30 Jun 2004 19:54:13 -0000 Message-ID: <40E31A63.8000604@dehora.net> Date: Wed, 30 Jun 2004 20:54:11 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: atom-syntax Subject: Re: PacePutIpAddrInEntry References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net> In-Reply-To: <40E3091B.8060202@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sam Ruby wrote: > I discussed a case[2] recently where somebody "anonymously" updated the > wiki. Somebody proporting to be Bill de hÓra stepped forward and > claimed responsibility. Truth be told, I personally trust the ip > addresses information more than the SMTP headers. I observe that you trust some the evidence of some sets of SMTP headers more than others ;) Datapoint: the name of the second ip address listed on your wiki ("83-70-35-17") is not the same of as the name of the ip address that entry was authored from ("192.168.123.143") cheers Phosphorus From owner-atom-syntax@mail.imc.org Wed Jun 30 16:14:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12676 for ; Wed, 30 Jun 2004 16:14:53 -0400 (EDT) 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 i5UK1S5v031731; Wed, 30 Jun 2004 13:01:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UK1StC031730; Wed, 30 Jun 2004 13:01:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UK1Rp4031723 for ; Wed, 30 Jun 2004 13:01:27 -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 1BflGp-0004kN-VQ; Wed, 30 Jun 2004 20:01:28 +0000 Message-ID: <40E31C15.2090409@franklinmint.fm> Date: Wed, 30 Jun 2004 16:01:25 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax Subject: Re: PacePutIpAddrInEntry References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net> In-Reply-To: <40E3091B.8060202@intertwingly.net> 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > I track and publish[1] IP addresses on my weblog. It has cut down > significantly on "spoofing". > I discussed a case[2] recently where somebody "anonymously" updated > the wiki. OK. Perhaps an atom:received-from element would be more appropriate? The IP address for a given author could vary quite a bit, but the one would expect that the other children of Author would remain relatively constant. ... .... x.x.x.x .... ... In the example above, the children of received-from indicate where the entry came from--not who wrote it.As a child of author, the geo:location element might be expected to point to the author's home, while the geo:location element under atom:recieved from might be expected to point to the author's location at the time she clicked "send" on her blackberry. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jun 30 16:19:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12892 for ; Wed, 30 Jun 2004 16:19:18 -0400 (EDT) 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 i5UK3vIe031893; Wed, 30 Jun 2004 13:03:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UK3vIa031892; Wed, 30 Jun 2004 13:03:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5UK3u9S031876 for ; Wed, 30 Jun 2004 13:03:57 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 80420 messnum 4176900 invoked from network[83.70.35.17/83-70-35-17.bas2.prp.dublin.eircom.net]); 30 Jun 2004 20:03:55 -0000 Received: from 83-70-35-17.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.35.17) by mail00.svc.cra.dublin.eircom.net (qp 80420) with SMTP; 30 Jun 2004 20:03:55 -0000 Message-ID: <40E31CA9.1010808@dehora.net> Date: Wed, 30 Jun 2004 21:03:53 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Atom-Syntax Subject: Re: author tag References: <14be96d304062419086ec02b78@mail.gmail.com> <40DEB5B1.1000302@intertwingly.net> <1C8301E6-C858-11D8-A9BF-000A95BD86C0@mnot.net> <40DF1957.1070901@bitworking.org> <40DF25CE.7020006@virgilio.it> <20040628135044.GI11231@google.com> <40E027C5.3050100@dehora.net> <40E05FEF.4020209@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Mon, 28 Jun 2004 19:14:07 +0100, Bill de hÓra wrote: >> Why not just markup the information explicitly? The less of a >> processing model we require around the Atom format the more useful it >> will be > > Of course, but duplicating (and possibly other Author > Construct) elements in a feed with 100 entries is not very cool. Glibly, if I was worried about this I wouldn't be using XML to begin with ;) It does have the twin benefits of being precise and unambiguous. Perhaps there is an inheritence processing model that is unambiguous, consistent and loseless for this and one that will also work with synthetic feeds, multiple authors, ip addresses and so on. We would then want to ensure only one such mechanism is used for the format. In other words -1 to ad-hoc inheritence mechanisms. But there is precedent that indicates that this kind of inheritence, as means of saving keystrokes or bits, has not always served us as an discipline well. >> There's perhaps no need. At a web arch level it's implied by the feed >> URIs. > > > I don't think an URI implies authorship. The feed might be syntethic, > and all sorts of other things. Yes, my bad. cheers Bill From owner-atom-syntax@mail.imc.org Wed Jun 30 16:19:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12956 for ; Wed, 30 Jun 2004 16:19:35 -0400 (EDT) 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 i5UK3qvh031883; Wed, 30 Jun 2004 13:03:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UK3qFm031882; Wed, 30 Jun 2004 13:03:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UK3p14031856 for ; Wed, 30 Jun 2004 13:03:51 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id E38227C0F3; Wed, 30 Jun 2004 23:00:27 +0200 (CEST) Date: Wed, 30 Jun 2004 22:07:20 +0200 To: "Mark Nottingham" Subject: Re: PacePutIpAddrInEntry Cc: Atom-Syntax References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> <89E6011F-CACC-11D8-B7F4-000A95BD86C0@mnot.net> 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: <89E6011F-CACC-11D8-B7F4-000A95BD86C0@mnot.net> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 12:34:44 -0700, Mark Nottingham wrote: > That sounds like a great use case for an Atom extension, but it's > completely outside of our charter to include such a mechanism in the > core protocol. I'm hoping to use Atom to carry stock tickers; should we > bake metadata for that into the Atom format? I think we can agree on that in Atom's primary use cases, an IP address will be both attainable and an interesting peice of information to have. It should imho be optional, but I can see many scenarios where it is useful. And a lot of these scenarios fall into the booths Atom is primarily trying to fill. In the end, I can't find a good reason _not_ to have an element in the feed (probably as a child of atom:author). -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 16:21:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13098 for ; Wed, 30 Jun 2004 16:21:01 -0400 (EDT) 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 i5UK6kLF032138; Wed, 30 Jun 2004 13:06:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UK6koI032137; Wed, 30 Jun 2004 13:06:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5UK6jah032129 for ; Wed, 30 Jun 2004 13:06:46 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 12842 messnum 4340932 invoked from network[83.70.35.17/83-70-35-17.bas2.prp.dublin.eircom.net]); 30 Jun 2004 20:06:44 -0000 Received: from 83-70-35-17.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.35.17) by mail05.svc.cra.dublin.eircom.net (qp 12842) with SMTP; 30 Jun 2004 20:06:44 -0000 Message-ID: <40E31D52.702@dehora.net> Date: Wed, 30 Jun 2004 21:06:42 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 CC: atom-syntax Subject: Re: PacePutIpAddrInEntry References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > I'm not talking about IP addresses identifying humans (although that is > done too), but as ways of identifying machines. There are many contexts > where a machine, not a person, is the creator of an entry. This isn't a use case I've heard put forward by the Pace's author. It seems to suggest some kind of mutual exclusion between ipaddr and the other stuff. cheers Bill From owner-atom-syntax@mail.imc.org Wed Jun 30 16:25:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13787 for ; Wed, 30 Jun 2004 16:25:04 -0400 (EDT) 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 i5UKDJ4S032760; Wed, 30 Jun 2004 13:13:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKDJLu032759; Wed, 30 Jun 2004 13:13:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKDHFc032752; Wed, 30 Jun 2004 13:13:17 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <89E6011F-CACC-11D8-B7F4-000A95BD86C0@mnot.net> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> <89E6011F-CACC-11D8-B7F4-000A95BD86C0@mnot.net> Date: Wed, 30 Jun 2004 13:13:19 -0700 To: Mark Nottingham From: Paul Hoffman / IMC Subject: Re: PacePutIpAddrInEntry Cc: atom-syntax , Sam Ruby Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:34 PM -0700 6/30/04, Mark Nottingham wrote: >On Jun 30, 2004, at 11:23 AM, Paul Hoffman / IMC wrote: > >>I'm hoping Atom gets used for feeds of status alerts from hosts, >>for example. In that case, an IP address or a DNS name are >>reasonable identifiers. > >That sounds like a great use case for an Atom extension, but it's >completely outside of our charter to include such a mechanism in the >core protocol. I'm hoping to use Atom to carry stock tickers; should >we bake metadata for that into the Atom format? That's a perfectly reasonable point. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Jun 30 16:28:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14235 for ; Wed, 30 Jun 2004 16:28:44 -0400 (EDT) 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 i5UKAvZn032442; Wed, 30 Jun 2004 13:10:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKAviL032441; Wed, 30 Jun 2004 13:10:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UKAubs032423 for ; Wed, 30 Jun 2004 13:10:56 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 33BD57C112; Wed, 30 Jun 2004 23:07:33 +0200 (CEST) Date: Wed, 30 Jun 2004 22:14:27 +0200 To: "Mark Nottingham" Subject: Re: PacePutIpAddrInEntry Cc: Atom-Syntax References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net> <8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net> 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: <8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 12:41:56 -0700, Mark Nottingham wrote: > Put it this way; would you trust an field in a post that > someone made to your blog over the IP address that your system thinks > they're coming from? Both can be spoofed, but I think you'll agree it's > technically easier to spoof the XML. I wouldn't trust the contents of an element if it was received through some kind of remote comment mechanism -- I would see the element as useful in the end of the flow; on my site. I would probably not even save the contents of the received, but rather do a request on REMOTE_HOST and put that one into the Atom feed I serve from my site. I doubt would ever be used as some kind of authentication mechanism, it would mostly be used for logging and other use cases Sam has mentioned. The more I think of it, the more I support the element. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 16:49:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17014 for ; Wed, 30 Jun 2004 16:49:14 -0400 (EDT) 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 i5UKYtPa034579; Wed, 30 Jun 2004 13:34:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKYt5l034578; Wed, 30 Jun 2004 13:34:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UKYp0V034566; Wed, 30 Jun 2004 13:34:54 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id 09C5E7C0F3; Wed, 30 Jun 2004 23:31:29 +0200 (CEST) Date: Wed, 30 Jun 2004 22:38:28 +0200 To: "Paul Hoffman / IMC" Subject: Re: PacePutIpAddrInEntry Cc: Atom-Syntax References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> 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.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 11:23:06 -0700, Paul Hoffman / IMC wrote: > I'm hoping Atom gets used for feeds of status alerts from hosts, for > example. In that case, an IP address or a DNS name are reasonable > identifiers. Speaking of... Is there a common designation for IP addresses and DNS names we could use instead of 'ipaddr' or 'ip-address'? Both DNS names and IP addresses should be possible to use to point to a node of origin, but I'm not sure what name the element should have to fit both. Any ideas? -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 16:58:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17908 for ; Wed, 30 Jun 2004 16:58:25 -0400 (EDT) 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 i5UKiO8r035786; Wed, 30 Jun 2004 13:44:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKiOjm035785; Wed, 30 Jun 2004 13:44:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from lakermmtao11.cox.net (lakermmtao11.cox.net [68.230.240.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKiNLg035777 for ; Wed, 30 Jun 2004 13:44:23 -0700 (PDT) (envelope-from millennium@spoonybards.net) Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao11.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040630204416.FRHK25349.lakermmtao11.cox.net@[10.0.1.2]>; Wed, 30 Jun 2004 16:44:16 -0400 Message-ID: <40E3261D.1010200@spoonybards.net> Date: Wed, 30 Jun 2004 16:44:13 -0400 From: Beecher Greenman User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken MacLeod , Atom-Syntax Subject: Re: PaceIntrospection: is another file format really needed? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ken MacLeod wrote: > Beecher Greenman writes: > > >>Again, I ask the following question: what exactly is a "feed"? Is it >>a concrete representation of a site or an entry, or is it an >>abstract representation of a list? I don't think we're going to be >>able to get much further in this until we nail down this definition. > > This is the critical point, so I moved it up here and reply to it > first. > > I agree in principle that a general solution would be nicer than a > specific format. I would prefer to go to a wholly general solution, > one that can be used to enable syndication but isn't inherently > syndication. I'm with you on that part. > > But, no. To me, atom:feed is a syndication feed. Then the spec needs to be altered to fit your opinion, because that is not what it says right now. > Extending it to an > index/archive format has shown its weaknesses for general tasks (which > feed headers are the "main" ones? why do the rest need all the > required elements when they could point to a site or category origin?) > Entries are being forced to be both log entries and metadata wrappers, > and they're pretty oddly defined metadata wrappers. I'll admit that some of the metadata definitions are odd, and not things I entirely understand (my biggest question, perhaps, being atom:issued versus atom:created). These, however, can be refined in their own proposals. It is entirely possible, in fact, that too many elements are currently required in the feed format. This can be refined further, as changing an element's status from required to optional (or the reverse) is far less painful on the development side than creating completely new elements or worse, completely new formats. However, this -required versus optional elements- speaks only to minor details of a format, mistakes made when people tried to make it too specific. Better to refine a format which is 95% of the way, rather than start from zero and changing definitions in the process. Changing the definition of a feed, as a dedicated introspection format will require in order to justify its existence, has far-reaching implications which are best left untouched. >>Again, XML models are cheap for standards developers, but not for >>standards implementors. The most enduring standards have proven to >>be the ones which are powerful enough to be useful in a wide array >>of tasks but simple enough to be relatively easy to implement. > > My analogy to database records earlier was misunderstood as some > specific kind of implementation, it was not; it was a comparison of > flexibility. XML content models are as flexible to work with as > database tables. I can't speak to writing tools that map flexible > formats to hard-wired objects as I prefer to use tools that expose the > flexibility. Maybe that is why I see XML constructs as cheap. Understood. At the same time, that is all theory; as with so many things, the reality often proves to not quite live up to the theory behind it. I agree with you that XML data models are as flexible to work with as database tables on paper. But just as database models, once they're set, they're set, and although changing them on paper remains easy, changing them in the real world becomes extremely painful. It's important, therefore, to get both of these things right the first time. The whole point of working groups is to figure out exactly what that means. The current proposals sacrifice the current spec genericity -based largely on what seems to be a misunderstanding of what a site is versus what a feed is- for a goal which needs no definitions to be changed. >>Once again, it's all a matter of doing the simplest thing that could >>possibly work. > > There are two parts to the DTSTTCPW rule: 1) implement a new > capability in the simplest, then 2) refactor. [1] > > You don't get a chance to refactor much after you've published a > public format or protocol. DTSTTCPW only applies during the iterative > development phase before final release. This is why we must pay > attention to long term use and extension. I agree completely, which is why I believe that we must keep things as generic as we can. - Beech From owner-atom-syntax@mail.imc.org Wed Jun 30 17:05:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19160 for ; Wed, 30 Jun 2004 17:05:02 -0400 (EDT) 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 i5UKnvOE036375; Wed, 30 Jun 2004 13:49:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKnvsG036374; Wed, 30 Jun 2004 13:49:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 i5UKnuPp036366 for ; Wed, 30 Jun 2004 13:49:57 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19]) by smtpgateway.itweb.no (Postfix) with ESMTP id CB7FC7C0F3; Wed, 30 Jun 2004 23:46:33 +0200 (CEST) Date: Wed, 30 Jun 2004 22:53:38 +0200 To: "Antone Roundy" Subject: Re: PacePersonRef posted References: <2932EE92-CAAC-11D8-B980-003065EA6144@geckotribe.com> Cc: Atom-Syntax 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: <2932EE92-CAAC-11D8-B980-003065EA6144@geckotribe.com> User-Agent: Opera M2/7.51 (Win32, build 3798) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 30 Jun 2004 09:42:58 -0600, Antone Roundy wrote: > Since I saw no objections to my email of a few days ago, I've posted > PacePersonRef Nice. Could you give at least one example of how it might look like (I think you wrote one in an e-mail not long ago)? > This proposal defines a method for creating person constructs at the > feed level (which do not apply directly to the feed as a whole) and then > referring to them from the feed level or within entries. Would it not be possible to have a «full» atom:author element inside atom:entry? E.g., should it only be possible to define authors at the feed level, and only refer to these at the entry level? And what do you mean by «referring to them from the feed»? Aren't the authors defined at the feed level? Would it then make sense to refer to these definitions also at the feed level? > Because referring to an author can be done compactly, inheritance by > entries that don't specify an author of the feed:author is removed. +1. > In most feeds, the author is the same for many, if not all, entries, > leading to repetition of author metadata. This can be avoided by > specifying the metadata in one place in the feed and referring to it > from other parts of the feed. Would it be possible to extend this Pace to also include external referring authors, which could be, e.g. a FOAF file? The file could of course also be a centrally stored XML file with an document in it, but when referring externally, I guess it makes more sense to refer to something more useful, like FOAF. > 4.5 atom:people Element > > The "atom:people" element is a container for atom:person elements. It > MAY contain any number of atom:person elements. Do we need this one? Isn't an element in the feed enough, if the intent is to not have inheritance and save bytes? Then, if an entry shares author with the feed, entry/author can refer to feed/author, if an entry doesn't have an author, no atom:author element is provided, and if the entry has another author than the feed, it just provides its own atom:author element. Shouldn't that cover most everything? > The "atom:person" element is a Person construct, and MUST follow all > requirements for Person constructs. Additionally, it MUST have an id > attribute. I don't see the need for another person construct element, but I understand where you're going with this, now. You're thinking of having an atom:people element in atom:feed which has several child nodes of atom:person, which again will be referred to by atom:author and possibly atom:contributor elements inside the entries. Right? Sounds like a decent idea, but I think it's a tad too complicated. Keeping the current model with atom:author elements, I think it's enough to add one (@ref) or three (@ref, @href and @type) attributes to the Person Construct. > The atom:person element's id attribute is a string. Can't it just be an xml:id? > It may contain any string «May» should not be used in any other context than «MAY» as per RFC 2119. «Might» is better. > which does not appear in the id attribute of any other atom:person > within the feed as it is served at a particular time. If we use xml:id, the value has to be unique within the document, no matter what element it occurs on. xml:id might show up on other elements in the future, and there's really no reason why an ID value shouldn't be locally unique, reagardless of what the ID is for. -- Asbjørn Ulsberg -=|=- asbjornu@hotmail.com «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Jun 30 17:19:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21087 for ; Wed, 30 Jun 2004 17:19:40 -0400 (EDT) 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 i5UL3SjF037141; Wed, 30 Jun 2004 14:03:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UL3STt037140; Wed, 30 Jun 2004 14:03:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from lakermmtao11.cox.net (lakermmtao11.cox.net [68.230.240.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UL3R0L037113 for ; Wed, 30 Jun 2004 14:03:27 -0700 (PDT) (envelope-from millennium@spoonybards.net) Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao11.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040630210325.FZJV25349.lakermmtao11.cox.net@[10.0.1.2]> for ; Wed, 30 Jun 2004 17:03:25 -0400 Message-ID: <40E32A9A.2060809@spoonybards.net> Date: Wed, 30 Jun 2004 17:03:22 -0400 From: Beecher Greenman User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceIntrospection: Is another file format really needed? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>> Perhaps the other question to ask is, should there really be any >>>> difference? >> No, the quesiton to ask is: "Should the Atom format requirements be >> extended to cater for Introspection?" No, it should not. The entire point behind my argument is that the format does not need to be extended at all; it already supports everything needed in order to be used for Introspection. I am arguing that we do not need a new format for Introspection, because we already have one that is perfectly usable and ready to go. It's odd; both sides here are arguing that "just because you can, doesn't mean you should"; we're just saying it about different things. I say that just because we can define a new XML format doesn't mean we should, because a perfectly usable one already exists and we must be wary of unnecessarily complicating our standard. Meanwhile, my opposition states that just because we can use feeds for introspection doesn't mean we should, because they see introspection as being somehow fundamentally different from syndication even if the data models are identical. The only real difference is that I believe the difference between introspection (as we define it) and syndication to be an artificial distinction, a limitation which does not currently exist and should not be added. >>>> "Subscribing" to a feed is something that one specific type of user >>>> will do. However, we cannot expect all users of Atom to be human. >> Those statements are not exclusive. True, and please forgive my poor word choice there. My point is that while most human uses of feeds will be limited to subscription -a point with which my opposition appears to agree- machines cannot be counted on to always follow that model. Some machines -such as browser-based aggregators- certainly will. However, not all machines can be counted on to do that. For an example of a machine use of feeds which does not deal with subscription, let us consider MemeGen, a popular tool on LiveJournal. This tool scrapes the RSS feeds of users' journals and "does stuff" (the "stuff" being largely determined by the user) depending on the contents it finds. Is this a trivial example? It probably is. At the same time, it does illustrate that there are uses for feeds outside of syndication and subscription. Now, let's throw introspection into the mix, such that a tool could scrape _all_ of a user's journals. LiveJournal does not offer this, but other blogging services do, and it's inevitable that at some point, MemeGen-like tools will be offered for these. If we were to take this to another level, let us consider a sort of "recursive MemeGen" which could spider the links from a feed, thus gathering not only the words a user has posted on his own site, but words from sites which the user deemed important enough to link. In a case like this, syndication and introspection become practically one and the same thing. >>>> Indeed, part of the reason to use XML for this format is that it >>>> can be relatively easily consumed by both humans and machines. >> This is not the same argument as requiring a unified format. Indeed not, but again, I am not proposing any changes to any formats. I am arguing that an existing format is essentially "unified" already. In fact, I'll go a step further and try to show how this "unification" is inherent in the natures of syndication and introspection, and cannot be taken out of the file as long as either one of these uses remains important. What does an Introspection file need? If the PaceIntrospection format is to be believed, then it basically needs the following: - It must be able to cover multiple sites. - It must be able to present links to each site. In Introspection's case, at least three particular types of links are needed if they exist: Feed, Post, and an alternate format which will usually (though not necessarily always) point to an HTML-based page. - It must provide some way of telling one site apart from another. The feed format already provides all of these things. Everyone agrees that the primary use case of the feed format is syndication; where we disagree is on whether or not syndication is its only valid function. However, if the feed format were ever to lose one of these three capabilities, it would not only be unsuitable for introspection, but it would also be unsuitable for syndication, which also requires these three capabilities. It would make no sense to render a format unsuitable for its primary use case, so we basically have a guarantee that the feed format will stay usable for introspection as well as syndication. Onward to the four points on which you requested clarification: >>>> Most machine-based uses are unlikely to work on a model of >>>> subscriptions, and so they need no such distinction. > >> 1. My inclusion of the word "most" was a poor one, and I apologize for the wording there. However, I maintain that many machine-centric uses of Atom will not work on a model of syndication and subscription, but will still require both introspection and "syndication" feeds. It seems, therefore, that developing the feed format strictly for syndication is unwise and unnecessarily limiting. >>>> Indeed, many of the scenarios under which a machine will use >>>> introspection are similar -if not identical- to the scenarios in >>>> which they would use syndication. > >> 2. I have named one scenario which uses syndication without subscription, and could use introspection in the same ways as syndication. Would you like more examples? >>>> At the same time, it is not the least bit harmful for them to have >>>> this ability if they desire it. > >> 3. The above quite, to restore context, references the ability of a user to "subscribe" to an Introspection file as though it were a feed; I maintain that there is no harm in this. If you believe there is harm, then show it to me. How is a user harmed by the ability to subscribe to introspection? I will assume that you are not limiting the scope of the harm to the user who is doing the subscribing. Do you feel that there might be some kind of privacy issue involved? From where I sit, this is the only potential possibility for harm. However, it remains an issue no matter what form of Introspection we eventually choose; programs which "subscribe" to Introspection files can be written even if we make it unnecessarily complex to do so. We could "lock" Introspection files behind authentication, but this same thing -indeed, any security measures one might take- could also apply to syndication feeds, and in fact would be useful in many of the same ways. A wise user, if he is worried about the privacy of his Introspection file, will also be worried about the privacy of his syndication feeds. >>>> I do, however, see harm in forcing an artificial distinction >>>> between different kinds of lists of data onto machines when the >>>> data models are essentially the same. > >> 4. I have already stated why the the data models for syndication and introspection are basically the same, and my opposition appears to agree with me on this point. Therefore, the question becomes, is there harm in artificially separating the specifications of two lists which follow the same model? I argue that from an implementation standpoint there is harm, because it increases the complexity of the standard by adding yet another format, when adding that format yields no real gain, in usability or otherwise. Complicating a standard for no gain is meaningless. A couple of messages ago, Kai mentioned the problem that this provides no ability to tell whether a feed is for syndication or introspection without looking at the URL. I maintain that this is not an issue, because clients already have to know the URL in order to access the file. This is a consequence of the REST design which we have undertaken to use, and if we intend to continue along that paradigm, then the URL is certainly a valid place from which to get data about a request, just as a function name would be. If there is truly a need to make this kind of type-identification self-contained, then the problem is by no means unique to syndication vs. introspection. There are already two "kinds" of feeds, to use the terms my opposition has used: - The feed represents a site, and the entries represent articles on that site. - The feed represents an article, and the entries represent comments on that article. It stands to reason that a third "kind" of feed will become popular in short order, even though it's not explicitly defined: - The feed represents a category of articles within a site, and the entries represent articles within that category. In the case of feed-based introspection, we add a fourth "kind": - The feed represents a user, and the entries represent sites for which that user is responsible. If there is really a need to distinguish between these "kinds" of feeds inside the feeds themselves -I maintain that there is no need, but let us assume that one arises- this could be dealt with a new attribute, perhaps "/atom:feed@type,". This could take values of "site", "article", "category", "introspection", or whatever other sort of feed might be needed. According to my opposition's logic this element is already necessary, to distinguish between "site feeds" and "article feeds". I do not follow this logic, but there it is. >> I need an explanation why Introspection support ought to be a >> requirement for the format. My point is that Introspection support need not be a "requirement" for the format. the requirements for the format already make it inherently usable for introspection, and that this is not going to change unless the whole idea of syndication is scrapped. I maintain that feed-based introspection is a perfectly logical use of the existing standard, being -at least as far as Atom understands the term- nothing more than a different sort of syndication: that of sites instead of articles. - Beecher Greenman From owner-atom-syntax@mail.imc.org Wed Jun 30 18:58:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27569 for ; Wed, 30 Jun 2004 18:58:04 -0400 (EDT) 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 i5UMfDpb056926; Wed, 30 Jun 2004 15:41:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UMfDXF056925; Wed, 30 Jun 2004 15:41:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@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 SMTP id i5UMfC6X056915 for ; Wed, 30 Jun 2004 15:41:13 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id d19so470770rnf for ; Wed, 30 Jun 2004 15:41:17 -0700 (PDT) Received: by 10.38.81.73 with SMTP id e73mr5043rnb; Wed, 30 Jun 2004 15:41:17 -0700 (PDT) Message-ID: <14be96d3040630154143084428@mail.gmail.com> Date: Wed, 30 Jun 2004 18:41:17 -0400 From: Mark Pilgrim To: Mark Nottingham Subject: Re: PacePutIpAddrInEntry Cc: Sam Ruby , atom-syntax In-Reply-To: <8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net> <8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 30 Jun 2004 12:41:56 -0700, Mark Nottingham wrote: > Put it this way; would you trust an field in a post that > someone made to your blog over the IP address that your system thinks > they're coming from? Both can be spoofed, but I think you'll agree it's > technically easier to spoof the XML. No, but that's an irrelevant argument. I wouldn't trust the name they typed in, or their email address, or their URL either. What's your point? Sam has specified a very clear use case for atom:author:ipaddr *that our own Atom project wiki could benefit from immediately*. "It could be forged" is not a counterargument; any un-cryptographically-signed data could be forged. ("You'll need to deal with privacy laws in the EU" is similarly specious. If you are subject to such laws, then deal with them. Atom is just a data format. Obviously you can use it to do illegal things.) I am in favor of atom:author:ipaddr in the core spec, because it would be immediately useful to a known class of existing Atom-enabled implementations, including our own wiki. I am also in favor of some way of unambiguously notating that nothing at all is known about the author of this feed and/or entry, and still having a valid Atom feed (something you can not currently do in 0.3). I have no opinion at all on how this is actually accomplished, or how it should interact with our (currently undocumented) author inheritance model. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed Jun 30 19:30:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28956 for ; Wed, 30 Jun 2004 19:30:31 -0400 (EDT) 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 i5UNHeSF063717; Wed, 30 Jun 2004 16:17:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UNHebt063716; Wed, 30 Jun 2004 16:17:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNHdsc063702 for ; Wed, 30 Jun 2004 16:17:40 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [67.119.69.246] (unknown [63.96.168.5]) by mail.mnot.net (Postfix) with ESMTP id 22241727D; Wed, 30 Jun 2004 16:17:45 -0700 (PDT) In-Reply-To: <14be96d3040630154143084428@mail.gmail.com> References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net> <8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net> <14be96d3040630154143084428@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax , Sam Ruby X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PacePutIpAddrInEntry Date: Wed, 30 Jun 2004 16:17:40 -0700 To: Mark Pilgrim X-Mailer: Apple Mail (2.618) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 30, 2004, at 3:41 PM, Mark Pilgrim wrote: > On Wed, 30 Jun 2004 12:41:56 -0700, Mark Nottingham > wrote: >> Put it this way; would you trust an field in a post that >> someone made to your blog over the IP address that your system thinks >> they're coming from? Both can be spoofed, but I think you'll agree >> it's >> technically easier to spoof the XML. > > No, but that's an irrelevant argument. I wouldn't trust the name they > typed in, or their email address, or their URL either. What's your > point? Sam has specified a very clear use case for atom:author:ipaddr > *that our own Atom project wiki could benefit from immediately*. Please to explain how. What are the specific benefits? Walk me through the scenario that conveys a benefit brought out by this particular feature that could not be realised if it weren't part of the core atom standard. Why, if this feature is so earnestly needed, has there not been a widely-deployed RSS extension for it? I'm incredibly wary of baking this into Atom just because it seems like a nifty, off-the-cuff idea. This is why we have an extensibility model. > ("You'll need to deal with privacy laws in the EU" is similarly > specious. If you are subject to such laws, then deal with them. Atom > is just a data format. Obviously you can use it to do illegal > things.) Well, it's all just bits, Mark. Protocols and formats can encourage and discourage certain activities by their design; if we put atom:ipaddr into the core format, most people will build some level of support for it into their tools, and most users will unthinkingly use it, because "it's there." This is human nature, and if we design the protocol and format to regularly rub against things like data protection, there will be problems. > I am also in favor of some > way of unambiguously notating that nothing at all is known about the > author of this feed and/or entry, and still having a valid Atom feed > (something you can not currently do in 0.3). +1 -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 30 19:42:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29446 for ; Wed, 30 Jun 2004 19:42:52 -0400 (EDT) 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 i5UNRG1j065561; Wed, 30 Jun 2004 16:27:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UNRGLf065560; Wed, 30 Jun 2004 16:27:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNRGeF065525 for ; Wed, 30 Jun 2004 16:27:16 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134]) by comcast.net (rwcrmhc11) with SMTP id <2004063023271601300bfd0ve>; Wed, 30 Jun 2004 23:27:16 +0000 Date: Wed, 30 Jun 2004 17:27:14 -0600 Subject: Re: PacePersonRef posted Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: Message-Id: <04FFFA1D-CAED-11D8-B980-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5UNRGeF065555 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Could you give at least one example of how it might look like (I think > you wrote one in an e-mail not long ago)? Okay, here's a feed with things not relevant to this proposal omitted (I'll add this to the Pace): Arthur McFeed John Doe Jane Smith http://www.janesmith.com/ Sylvester McMonkey McBean I'm in two minds for this: it provides an extensibility path, but it opens awkward questions about what happens if the referenced element is not a construct > 4.5.1.1 id Attribute > 3.2.1 "ref" attribute we need some extra language to explain that any given construct can have @id or @ref but NOT both. e.