From owner-atom-syntax@mail.imc.org Fri Oct 1 12:38:57 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 MAA22545 for ; Fri, 1 Oct 2004 12:38:57 -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 i91GPWhn039651; Fri, 1 Oct 2004 09:25: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 i91GPWf5039650; Fri, 1 Oct 2004 09:25:32 -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 i91GPVFm039628; Fri, 1 Oct 2004 09:25:31 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i91GPkQU020274; Fri, 1 Oct 2004 12:25:47 -0400 Message-ID: <415D84EA.9070308@intertwingly.net> Date: Fri, 01 Oct 2004 12:25:14 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: Type for content References: 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: > > The purpose of this note is to sound out the WG's opinion about how to > go forward; a bit of meta-debate. > > Some obvious options are: > > - Go ahead and roll in ReformedContent3 > - The same, but with the understanding that we then argue about type= > - Preserve the current type/mode attribute pair; rewrite ReformedContent > to do so > - The same, but add the "TEXT", "HTML", and "XHTML" keywords (or > lower-case equivalents) to type= since these thing aren't really > text/plain, text/html, or application/xhtml There is not an option in that list that I would violently object to. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Oct 1 12:50: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 MAA23624 for ; Fri, 1 Oct 2004 12:50:29 -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 i91GgOZA040598; Fri, 1 Oct 2004 09:42: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 i91GgOHL040597; Fri, 1 Oct 2004 09:42:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91GgO2a040583; Fri, 1 Oct 2004 09:42:24 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail09-en1 [10.13.10.98]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i91GgRSr020605; Fri, 1 Oct 2004 09:42:27 -0700 (PDT) Received: from webmail09 (localhost [127.0.0.1]) by mac.com (Xserve/webmail09/MantshX 4.0) with ESMTP id i91GgQ5P020352; Fri, 1 Oct 2004 09:42:26 -0700 (PDT) Message-ID: <16109805.1096648945925.JavaMail.dtcd@mac.com> Date: Fri, 01 Oct 2004 09:42:25 -0700 From: Graham Parks To: Sam Ruby Subject: Re: Type for content Cc: Paul Hoffman / IMC , Atom WG in-reply-to: <415D84EA.9070308@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <415D84EA.9070308@intertwingly.net> X-Originating-IP: 161.73.13.14/instID=45 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >Paul Hoffman / IMC wrote: > > - Go ahead and roll in ReformedContent3 > - The same, but with the understanding that we then argue about type= > - Preserve the current type/mode attribute pair; rewrite ReformedContent > to do so > - The same, but add the "TEXT", "HTML", and "XHTML" keywords (or > lower-case equivalents) to type= since these thing aren't really > text/plain, text/html, or application/xhtml How is this last one different from RC3? +1 to RC3. Graham From owner-atom-syntax@mail.imc.org Fri Oct 1 13:04: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 NAA24906 for ; Fri, 1 Oct 2004 13:04: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 i91GwSeH042006; Fri, 1 Oct 2004 09:58: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 i91GwSDv042005; Fri, 1 Oct 2004 09:58:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91GwRVc041991; Fri, 1 Oct 2004 09:58:27 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i91GwS53001968; Fri, 1 Oct 2004 10:58:28 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4X001080HGSW@edgemail1.Central.Sun.COM>; Fri, 01 Oct 2004 10:58:28 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4X000JB0HFW1@mail.sun.net>; Fri, 01 Oct 2004 10:58:28 -0600 (MDT) Date: Fri, 01 Oct 2004 09:58:33 -0700 From: Tim Bray Subject: Re: Type for content In-reply-to: <415D84EA.9070308@intertwingly.net> To: Sam Ruby Cc: Paul Hoffman / IMC , Atom WG Message-id: <20F7BD75-13CB-11D9-8EE5-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <415D84EA.9070308@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 1, 2004, at 9:25 AM, Sam Ruby wrote: >> Some obvious options are: >> - Go ahead and roll in ReformedContent3 >> - The same, but with the understanding that we then argue about type= >> - Preserve the current type/mode attribute pair; rewrite >> ReformedContent to do so >> - The same, but add the "TEXT", "HTML", and "XHTML" keywords (or >> lower-case equivalents) to type= since these thing aren't really >> text/plain, text/html, or application/xhtml > > There is not an option in that list that I would violently object to. What Sam said. I'm pretty well convinced that the usefulness and adoption of Atom would be about the same with all options. I'd prefer the first choice but can live with any; if any three or four people pipe up saying "I like option X" Paul and I would be tempted to say "fine" and try to declare consensus. Alternatively, if a few more people pipe up like Sam and me saying "could live with any", then we should maybe just do a survey and go with the winner. Then we could move on to things that really matter. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 1 13:19:16 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 NAA27403 for ; Fri, 1 Oct 2004 13:19:16 -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 i91H9JPk042789; Fri, 1 Oct 2004 10:09: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 i91H9Jkt042788; Fri, 1 Oct 2004 10:09:19 -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 i91H9ISZ042775; Fri, 1 Oct 2004 10:09:18 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i91H9aUG022581; Fri, 1 Oct 2004 13:09:36 -0400 Message-ID: <415D8F30.6020306@intertwingly.net> Date: Fri, 01 Oct 2004 13:09:04 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Paul Hoffman / IMC , Atom WG Subject: Re: Type for content References: <415D84EA.9070308@intertwingly.net> <20F7BD75-13CB-11D9-8EE5-000A95A51C9E@sun.com> In-Reply-To: <20F7BD75-13CB-11D9-8EE5-000A95A51C9E@sun.com> 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 Tim Bray wrote: > > I'd prefer the first choice but can live with any; if any three or four > people pipe up saying "I like option X" Paul and I would be tempted to > say "fine" and try to declare consensus. I prefer it RC3 were rolled in, and the door were left open for new Paces to modify this. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Oct 1 13:28: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 NAA28417 for ; Fri, 1 Oct 2004 13:28: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 i91HL72o043645; Fri, 1 Oct 2004 10:21:07 -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 i91HL7pB043644; Fri, 1 Oct 2004 10:21:07 -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 i91HL7T1043630; Fri, 1 Oct 2004 10:21:07 -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 1CDR5b-00087t-5T; Fri, 01 Oct 2004 17:21:03 +0000 Message-ID: <415D91FB.6020901@franklinmint.fm> Date: Fri, 01 Oct 2004 13:20:59 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Tim Bray , Paul Hoffman / IMC , Atom WG Subject: Re: Type for content References: <415D84EA.9070308@intertwingly.net> <20F7BD75-13CB-11D9-8EE5-000A95A51C9E@sun.com> <415D8F30.6020306@intertwingly.net> In-Reply-To: <415D8F30.6020306@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 prefer it RC3 were rolled in, and the door were left open for new > Paces to modify this. > +1 Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 1 13:41: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 NAA29232 for ; Fri, 1 Oct 2004 13:41: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 i91HZDpl044597; Fri, 1 Oct 2004 10:35: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 i91HZDrO044596; Fri, 1 Oct 2004 10:35:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91HZDZb044589 for ; Fri, 1 Oct 2004 10:35:13 -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 (sccrmhc12) with SMTP id <2004100117350801200n4j59e>; Fri, 1 Oct 2004 17:35:09 +0000 Date: Fri, 1 Oct 2004 11:35:08 -0600 Subject: Re: PaceReformedContent3 - @type and @mode 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: <20040930001513.66197.qmail@web41203.mail.yahoo.com> Message-Id: <3CF55E50-13D0-11D9-84B6-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, September 29, 2004, at 06:15 PM, Dare Obasanjo wrote: > Then there is the fact that both attributes can be > combined in ways that don't make logical sense but > would in fact be valid (e.g. mode='xml' & > type='text/html' or mode='text/plain' and > mode='base64' from Atom 0.3). Perhaps the problem is that we have the "wrong" names for @mode values. There's a parallel for what we're doing here in MIME. does not map to: Content-Type: application/xhtml+xml Content-Transfer-Encoding: xml but perhaps: Content-Type: application/xhtml+xml Content-Transfer-Encoding: 8bit "base64" and "escaped" are both fine names--both tell the consuming application exactly what to do with the content to turn it into the type specified by @type. But instead of saying, "you don't have to transform this", "xml" reads as if it were talking about the content type. Maybe a name like "literal", "inline", "unencoded"...would communicate the idea better. And in fact, "encoding" might be more obvious than "mode". But that will all be moot if PaceReformedContent3 does away with @mode, which I don't think is a bad idea. I just bring it up in case anyone was having trouble letting go of @mode, even though they were dissatisfied with it. BTW, I don't see a problem with text/plain as base64, for example. text/html as xml is problematic, because even if all tags are closed properly, etc., the HTML elements, appearing without namespaces, would look like they were in Atom's namespace (unless the feed didn't use a default namespace). But I don't see that as a weakness of the system. It's similar to the reason for having transfer encodings in MIME--some data simply can't be transferred unencoded in some circumstances (over 7 bit networks...). From owner-atom-syntax@mail.imc.org Fri Oct 1 23:04: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 XAA02109 for ; Fri, 1 Oct 2004 23:04: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 i922sYO3076514; Fri, 1 Oct 2004 19:54: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 i922sYcu076513; Fri, 1 Oct 2004 19:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i922sXaF076505 for ; Fri, 1 Oct 2004 19:54:33 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020254.i922sXaF076505@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 19:55:58 -0700 From: "Jon Davis" To: Subject: Default atom:content item Date: Fri, 1 Oct 2004 19:54:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C4A7F0.79016260" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoKyQx2+r8909aRNG35szw8Asomw== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C4A7F0.79016260 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'm new on this list (since months ago), so perhaps this was discussed before. Looking at v0.3, I see that an atom:entry element may contain more than one atom:content element. A content element in an entry element can also contain one or more content elements (/feed/entry/content/content++). I like this, as it allows for attachments and such. But if an atom:entry element can contain more than one child atom:content nodes (/feed/entry/content++), one of those content elements should be marked as a "default" or "master" item, which would normally the XHTML representation of the item. In my implementation, I am going to either watch for a "default" attribute with a value of true, or if that isn't found I will use the first item in the list. This will allow my implementation to be "backwards compatible" with those flawed implementations out there that I've found that DO NOT recognize that more than one atom:content element can be used, as well as give me and users of my implementation to have a fallback mechanism that presumes a single content entry. - Jon Davis ------=_NextPart_000_00C2_01C4A7F0.79016260 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I'm = new on this list=20 (since months ago), so perhaps this was discussed = before.
 
Looking at v0.3, I=20 see that an atom:entry element may contain more than one atom:content = element. A=20 content element in an entry element can also contain one or more content = elements (/feed/entry/content/content++). I like this, as it allows for=20 attachments and such.
 
But if = an atom:entry=20 element can contain more than one child atom:content nodes=20 (/feed/entry/content++), one of those content elements should be = marked as=20 a "default" or "master" item, which would normally the XHTML = representation of=20 the item.
 
In=20 my implementation, I am going to either watch for a "default" = attribute=20 with a value of true, or if that isn't found I will use the first item = in the=20 list. This will allow my implementation to be "backwards compatible" = with those=20 flawed implementations out there that I've found that DO NOT = recognize=20 that more than one atom:content element can be used, as well as give me = and=20 users of my implementation to have a fallback mechanism that presumes a = single=20 content entry.
 
- Jon=20 Davis
 
------=_NextPart_000_00C2_01C4A7F0.79016260-- From owner-atom-syntax@mail.imc.org Fri Oct 1 23:33:55 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 XAA03267 for ; Fri, 1 Oct 2004 23:33:54 -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 i923PTs3077865; Fri, 1 Oct 2004 20:25:29 -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 i923PTaY077864; Fri, 1 Oct 2004 20:25:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i923PSDP077857 for ; Fri, 1 Oct 2004 20:25:28 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041002032530.60622.qmail@web41214.mail.yahoo.com> Received: from [67.160.85.184] by web41214.mail.yahoo.com via HTTP; Fri, 01 Oct 2004 20:25:30 PDT Date: Fri, 1 Oct 2004 20:25:30 -0700 (PDT) From: Dare Obasanjo Subject: Re: Default atom:content item To: Jon Davis , atom-syntax@imc.org In-Reply-To: <200410020254.i922sXaF076505@above.proper.com> 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: --- Jon Davis wrote: > > But if an atom:entry element can contain more than > one child atom:content > nodes (/feed/entry/content++), one of those content > elements should be > marked as a "default" or "master" item, which would > normally the XHTML > representation of the item. That makes sense but the Atom 0.3 spec does not specify a mechanism for doing this. Considering that the Atom 0.3 spec was just intended to be a rough draft it is unsurprising that there are holes in the spec such as these. > In my implementation, I am going to either watch for > a "default" attribute > with a value of true, or if that isn't found I will > use the first item in > the list. This will allow my implementation to be > "backwards compatible" > with those flawed implementations out there that > I've found that DO NOT > recognize that more than one atom:content element > can be used, as well as > give me and users of my implementation to have a > fallback mechanism that > presumes a single content entry. I'm confused by your use of the phrase "backwards compatible". I assume you mean "compatible" not so? Also I wonder why you are planning on making your implementation create made up attributes for the atom:content element which are not in the spec nor have they been specified in the IETF drafts of the Atom spec. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Fri Oct 1 23:51: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 XAA04102 for ; Fri, 1 Oct 2004 23:51: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 i923jrQx078927; Fri, 1 Oct 2004 20:45: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 i923jr8w078926; Fri, 1 Oct 2004 20:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i923jrMN078920 for ; Fri, 1 Oct 2004 20:45:53 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020345.i923jrMN078920@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 20:47:30 -0700 From: "Jon Davis" To: Subject: RE: Default atom:content item Date: Fri, 1 Oct 2004 20:45:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <20041002032530.60622.qmail@web41214.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoL8vWJ3ZapIA5S9CHfSLvL9JFrgAAnSsA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I'm confused by your use of the phrase "backwards compatible". I > assume you mean "compatible" not so? Yes, compatible, not backwards compatible. > Also I wonder why you are planning on making your implementation > create made up attributes for the atom:content element which are not > in the spec nor have they been specified in the IETF drafts of the > Atom spec. As you said, "Atom 0.3 [draft] spec does not specify a mechanism for doing this" because "the Atom 0.3 spec was just intended to be a rough draft it is unsurprising that there are holes in the spec". If the draft spec has since been modified, I would greatly appreciate the education of the proper mechanism. Until then, implementors are free to extend specs, as there is nothing in the atom:content specification that indicates that there must be no other attributes in this element. This is a good thing, too; in XML implementations it is generally a bad idea to disallow custom attributes to XML nodes unless there is a very good reason, simply because of the extensibility, or the 'X', of XML. I shared about my implementation because the spec proved insufficient in this area. I posted to this group to allow discussion of this mechanism; if anyone knows of a better idea for this mechanism, please share. Discussing the adaptation of the draft Atom specification, including the 0.3 draft, is the purpose of this list, is it not? Thanks, Jon -----Original Message----- From: Dare Obasanjo [mailto:kpako@yahoo.com] Sent: Friday, October 01, 2004 8:26 PM To: Jon Davis; atom-syntax@imc.org Subject: Re: Default atom:content item --- Jon Davis wrote: > > But if an atom:entry element can contain more than one child > atom:content nodes (/feed/entry/content++), one of those content > elements should be marked as a "default" or "master" item, which would > normally the XHTML representation of the item. That makes sense but the Atom 0.3 spec does not specify a mechanism for doing this. Considering that the Atom 0.3 spec was just intended to be a rough draft it is unsurprising that there are holes in the spec such as these. > In my implementation, I am going to either watch for a "default" > attribute with a value of true, or if that isn't found I will use the > first item in the list. This will allow my implementation to be > "backwards compatible" > with those flawed implementations out there that I've found that DO > NOT recognize that more than one atom:content element can be used, as > well as give me and users of my implementation to have a fallback > mechanism that presumes a single content entry. I'm confused by your use of the phrase "backwards compatible". I assume you mean "compatible" not so? Also I wonder why you are planning on making your implementation create made up attributes for the atom:content element which are not in the spec nor have they been specified in the IETF drafts of the Atom spec. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. From owner-atom-syntax@mail.imc.org Fri Oct 1 23:51:44 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 XAA04165 for ; Fri, 1 Oct 2004 23:51: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 i923kK7x078963; Fri, 1 Oct 2004 20:46: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 i923kJ4P078962; Fri, 1 Oct 2004 20:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i923kJof078956 for ; Fri, 1 Oct 2004 20:46:19 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020346.i923kJof078956@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 20:47:56 -0700 From: "Jon Davis" To: Subject: 1.0 draft spec? Date: Fri, 1 Oct 2004 20:46:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01C4A7F7.B3F8BC40" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoMl8yQIiE3d5ITceC0Q1ZxQU0ng== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C4A7F7.B3F8BC40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I've been working on implementing v0.3 as a versionized implementation since it has been said to be a different spec altogether from v1.0. Is there a 1.0 draft yet, and if so, what is its reference URL? Thanks, Jon ------=_NextPart_000_00D0_01C4A7F7.B3F8BC40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I've = been working=20 on implementing v0.3 as a versionized implementation since it has = been said=20 to be a different spec altogether from v1.0.
 
Is = there a 1.0 draft=20 yet, and if so, what is its reference URL?
 
Thanks,
Jon
------=_NextPart_000_00D0_01C4A7F7.B3F8BC40-- From owner-atom-syntax@mail.imc.org Sat Oct 2 00:09:22 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 AAA06572 for ; Sat, 2 Oct 2004 00:09:22 -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 i924070X079805; Fri, 1 Oct 2004 21:00:07 -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 i92407kr079804; Fri, 1 Oct 2004 21:00:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i92406cl079793 for ; Fri, 1 Oct 2004 21:00:06 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041002040008.65529.qmail@web41214.mail.yahoo.com> Received: from [67.160.85.184] by web41214.mail.yahoo.com via HTTP; Fri, 01 Oct 2004 21:00:08 PDT Date: Fri, 1 Oct 2004 21:00:08 -0700 (PDT) From: Dare Obasanjo Subject: RE: Default atom:content item To: Jon Davis , atom-syntax@imc.org 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: --- Jon Davis wrote: > If > the draft spec has since > been modified, I would greatly appreciate the > education of the proper > mechanism. The most recent Atom draft is at http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-02.txt > Until then, implementors are free to extend specs, > as there is nothing in > the atom:content specification that indicates that > there must be no other > attributes in this element. Interesting, I didn't realize the default rule for dealing with specs was embrace and extend if they were ambiguous. > This is a good thing, > too; in XML > implementations it is generally a bad idea to > disallow custom attributes to > XML nodes unless there is a very good reason, simply > because of the > extensibility, or the 'X', of XML. This is news to me. Where is this rule of dealing with Internet specifications written? > I shared about my implementation because the spec > proved insufficient in > this area. I posted to this group to allow > discussion of this mechanism; if > anyone knows of a better idea for this mechanism, > please share. > > Discussing the adaptation of the draft Atom > specification, including the 0.3 > draft, is the purpose of this list, is it not? Indeed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 2 00:15:40 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 AAA07572 for ; Sat, 2 Oct 2004 00:15:39 -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 i9248Sm6080222; Fri, 1 Oct 2004 21:08: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 i9248SDm080221; Fri, 1 Oct 2004 21:08:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9248STM080215 for ; Fri, 1 Oct 2004 21:08:28 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020408.i9248STM080215@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 21:10:09 -0700 From: "Jon Davis" To: "'Dare Obasanjo'" , Subject: RE: Default atom:content item Date: Fri, 1 Oct 2004 21:08:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <20041002040008.65529.qmail@web41214.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoNLV/xB5+oVe6Sk+BpNKVLgBR0gAAGkvw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > The most recent Atom draft is at > http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-02.txt Thank you. This answers my other thread. Would whoever is in charge of atomenabled.org please make the above URL clearly labeled as such? Or is that not the official information site for the Atom objective? Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Dare Obasanjo Sent: Friday, October 01, 2004 9:00 PM To: Jon Davis; atom-syntax@imc.org Subject: RE: Default atom:content item --- Jon Davis wrote: > If > the draft spec has since > been modified, I would greatly appreciate the education of the proper > mechanism. The most recent Atom draft is at http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-02.txt > Until then, implementors are free to extend specs, as there is nothing > in the atom:content specification that indicates that there must be no > other attributes in this element. Interesting, I didn't realize the default rule for dealing with specs was embrace and extend if they were ambiguous. > This is a good thing, > too; in XML > implementations it is generally a bad idea to disallow custom > attributes to XML nodes unless there is a very good reason, simply > because of the extensibility, or the 'X', of XML. This is news to me. Where is this rule of dealing with Internet specifications written? > I shared about my implementation because the spec proved insufficient > in this area. I posted to this group to allow discussion of this > mechanism; if anyone knows of a better idea for this mechanism, please > share. > > Discussing the adaptation of the draft Atom specification, including > the 0.3 draft, is the purpose of this list, is it not? Indeed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 2 00:25:16 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 AAA08444 for ; Sat, 2 Oct 2004 00:25:16 -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 i924GkUB080688; Fri, 1 Oct 2004 21:16: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 i924Gkao080687; Fri, 1 Oct 2004 21:16:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i924Gkui080681 for ; Fri, 1 Oct 2004 21:16:46 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020416.i924Gkui080681@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 21:18:29 -0700 From: "Jon Davis" To: "'Dare Obasanjo'" , Subject: RE: Default atom:content item Date: Fri, 1 Oct 2004 21:16:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <20041002040008.65529.qmail@web41214.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoNLV/xB5+oVe6Sk+BpNKVLgBR0gAAaWnA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > If > > the draft spec has since > > been modified, I would greatly appreciate the education of the proper > > mechanism. > > The most recent Atom draft is at > http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-02.txt The mechanism being discussed is not mentioned here. I am implementing with the default attribute as described in the original post of this thread until this group comes up with a better mechanism. Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Dare Obasanjo Sent: Friday, October 01, 2004 9:00 PM To: Jon Davis; atom-syntax@imc.org Subject: RE: Default atom:content item --- Jon Davis wrote: > If > the draft spec has since > been modified, I would greatly appreciate the education of the proper > mechanism. The most recent Atom draft is at http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-02.txt > Until then, implementors are free to extend specs, as there is nothing > in the atom:content specification that indicates that there must be no > other attributes in this element. Interesting, I didn't realize the default rule for dealing with specs was embrace and extend if they were ambiguous. > This is a good thing, > too; in XML > implementations it is generally a bad idea to disallow custom > attributes to XML nodes unless there is a very good reason, simply > because of the extensibility, or the 'X', of XML. This is news to me. Where is this rule of dealing with Internet specifications written? > I shared about my implementation because the spec proved insufficient > in this area. I posted to this group to allow discussion of this > mechanism; if anyone knows of a better idea for this mechanism, please > share. > > Discussing the adaptation of the draft Atom specification, including > the 0.3 draft, is the purpose of this list, is it not? Indeed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 2 01:18:59 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 BAA10928 for ; Sat, 2 Oct 2004 01:18:58 -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 i925B20d086643; Fri, 1 Oct 2004 22:11: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 i925B260086642; Fri, 1 Oct 2004 22:11:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i925B2eb086631 for ; Fri, 1 Oct 2004 22:11:02 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020511.i925B2eb086631@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 22:12:55 -0700 From: "Jon Davis" To: Subject: RE: Default atom:content item Date: Fri, 1 Oct 2004 22:10:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01C4A803.8620A0B0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <200410020254.i922sXaF076505@above.proper.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoKyQx2+r8909aRNG35szw8AsomwAD8VaA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00DD_01C4A803.8620A0B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > >> if an atom:entry element can contain more than one child atom:content >> nodes (/feed/entry/content++), one of those content elements should >> be marked as a "default" or "master" item, which would normally the >> XHTML representation of the item. >> I am going to either watch for a "default" attribute with a value of true, >> or if that isn't found I will use the first item in the list. > I am implementing with the default attribute as described in the original > post of this thread until this group comes up with a better mechanism. (While implementing I have noticed that the Content construct has two variants: one in which Content construct child elements ARE allowed, and one in which Content construct child elements are explicitly DISALLOWED. For purposes of discussion, I would like to refer to the latter variant as a Subcontent construct.) A content defaulting mechanism actually is suggested in the draft: >> Consumers SHOULD look at all alternative content elements and determine which one is most suitable, based on which @type and @mode the consumer supports, and preferences specified by the end user (if any). << However, there is nothing in the specification that indicates that there should only be one atom:content of a particular @type / @mode. That said, the file type based mechanism is acceptable as an alternative to a "default" attribute if two new rules are added to the entry element: 1. The atom:entry MAY contain more than one atom:content elements IF each atom:content element has a unique @type / @mode pair. 2. Readers SHOULD NOT refer to any individual atom:content child element of an atom:content element marked as "multipart/alternative" as the the primary content of the entry. Readers SHOULD instead determine the primary content of the entry from the hierarchy of child elements of atom:entry. As a third alternative, apply #1 above but apply it to atom:content children of atom:content (Subcontent constructs), and instead of #2, remove from the spec the allowance of multiple atom:content elements as children of atom:entry and require all instances of multiple atom:content elements to be under the "multipart/alternative"-typed atom:content element of atom:entry. Jon _____ From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon Davis Sent: Friday, October 01, 2004 7:55 PM To: atom-syntax@imc.org Subject: Default atom:content item I'm new on this list (since months ago), so perhaps this was discussed before. Looking at v0.3, I see that an atom:entry element may contain more than one atom:content element. A content element in an entry element can also contain one or more content elements (/feed/entry/content/content++). I like this, as it allows for attachments and such. But if an atom:entry element can contain more than one child atom:content nodes (/feed/entry/content++), one of those content elements should be marked as a "default" or "master" item, which would normally the XHTML representation of the item. In my implementation, I am going to either watch for a "default" attribute with a value of true, or if that isn't found I will use the first item in the list. This will allow my implementation to be "backwards compatible" with those flawed implementations out there that I've found that DO NOT recognize that more than one atom:content element can be used, as well as give me and users of my implementation to have a fallback mechanism that presumes a single content entry. - Jon Davis ------=_NextPart_000_00DD_01C4A803.8620A0B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
>
>> if = an atom:entry=20 element can contain more than one child atom:content
>> = nodes=20 (/feed/entry/content++), one of those content elements should =
>> be = marked as a=20 "default" or "master" item, which would normally the
>> = XHTML=20 representation of the item.
>> I = am going to=20 either watch for a "default" attribute with a value of true, =
>> or = if that isn't=20 found I will use the first item in the list.
 
 
> I am implementing with the = default=20 attribute as described in the original
> post of this thread until = this group=20 comes up with a better mechanism.
 
 
(While implementing I have noticed that the = Content=20 construct has two variants: one in which Content construct child = elements ARE=20 allowed, and one in which Content construct child elements are = explicitly=20 DISALLOWED. For purposes of discussion, I would like to refer to the = latter=20 variant as a Subcontent = construct.)
 
A content defaulting mechanism actually is = suggested in the=20 draft:
 
>>
Consumers SHOULD look at all
   alternative = content=20 elements and determine which one is most
   suitable, based = on=20 which @type and @mode the consumer supports, and
   = preferences=20 specified by the end user (if any).
<<
 
However, there is nothing in the specification = that=20 indicates that there should only be one atom:content of a = particular @type=20 / @mode.
 
That said, the file type based mechanism is = acceptable as=20 an alternative to a "default" attribute if two new=20 rules are added to the entry element:
 
1. The atom:entry MAY contain more than = one=20 atom:content elements IF each atom:content element has a unique @type = / @mode=20 pair.
2. Readers SHOULD NOT refer to any individual = atom:content=20 child element of an atom:content element marked as=20 "multipart/alternative" as the the primary content of the entry. Readers = SHOULD=20 instead determine the primary content of the entry from the hierarchy of = child=20 elements of atom:entry.
 
As a third alternative, apply #1 above but = apply it to=20 atom:content children of atom:content (Subcontent constructs), and = instead of=20 #2, remove from the spec the allowance of multiple = atom:content=20 elements as children of atom:entry and require all instances of multiple = atom:content elements to be under the "multipart/alternative"-typed = atom:content=20 element of atom:entry.
 
Jon
 

From: owner-atom-syntax@mail.imc.org = [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon=20 Davis
Sent: Friday, October 01, 2004 7:55 PM
To:=20 atom-syntax@imc.org
Subject: Default atom:content=20 item

I'm = new on this list=20 (since months ago), so perhaps this was discussed = before.
 
Looking at v0.3, I=20 see that an atom:entry element may contain more than one atom:content = element. A=20 content element in an entry element can also contain one or more content = elements (/feed/entry/content/content++). I like this, as it allows for=20 attachments and such.
 
But if = an atom:entry=20 element can contain more than one child atom:content nodes=20 (/feed/entry/content++), one of those content elements should be = marked as=20 a "default" or "master" item, which would normally the XHTML = representation of=20 the item.
 
In=20 my implementation, I am going to either watch for a "default" = attribute=20 with a value of true, or if that isn't found I will use the first item = in the=20 list. This will allow my implementation to be "backwards compatible" = with those=20 flawed implementations out there that I've found that DO NOT = recognize=20 that more than one atom:content element can be used, as well as give me = and=20 users of my implementation to have a fallback mechanism that presumes a = single=20 content entry.
 
- Jon=20 Davis
 
------=_NextPart_000_00DD_01C4A803.8620A0B0-- From owner-atom-syntax@mail.imc.org Sat Oct 2 01:24: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 BAA11107 for ; Sat, 2 Oct 2004 01:24:05 -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 i925H3MP088705; Fri, 1 Oct 2004 22:17:03 -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 i925H3qx088704; Fri, 1 Oct 2004 22:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i925H25v088691 for ; Fri, 1 Oct 2004 22:17:02 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020517.i925H25v088691@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 22:18:56 -0700 From: "Jon Davis" To: "'Jon Davis'" , Subject: RE: Default atom:content item Date: Fri, 1 Oct 2004 22:16:52 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01C4A804.5C8E1F10" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoKyQx2+r8909aRNG35szw8AsomwAD8VaAAADy6RA= Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00E4_01C4A804.5C8E1F10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The "third alternative" is far more limiting than the "second alternative", as it would disallow distinctive attachments of the same type. Ignore it. Jon _____ From: Jon Davis [mailto:jon@accentra.net] Sent: Friday, October 01, 2004 10:11 PM To: 'atom-syntax@imc.org' Subject: RE: Default atom:content item > >> if an atom:entry element can contain more than one child atom:content >> nodes (/feed/entry/content++), one of those content elements should >> be marked as a "default" or "master" item, which would normally the >> XHTML representation of the item. >> I am going to either watch for a "default" attribute with a value of true, >> or if that isn't found I will use the first item in the list. > I am implementing with the default attribute as described in the original > post of this thread until this group comes up with a better mechanism. (While implementing I have noticed that the Content construct has two variants: one in which Content construct child elements ARE allowed, and one in which Content construct child elements are explicitly DISALLOWED. For purposes of discussion, I would like to refer to the latter variant as a Subcontent construct.) A content defaulting mechanism actually is suggested in the draft: >> Consumers SHOULD look at all alternative content elements and determine which one is most suitable, based on which @type and @mode the consumer supports, and preferences specified by the end user (if any). << However, there is nothing in the specification that indicates that there should only be one atom:content of a particular @type / @mode. That said, the file type based mechanism is acceptable as an alternative to a "default" attribute if two new rules are added to the entry element: 1. The atom:entry MAY contain more than one atom:content elements IF each atom:content element has a unique @type / @mode pair. 2. Readers SHOULD NOT refer to any individual atom:content child element of an atom:content element marked as "multipart/alternative" as the the primary content of the entry. Readers SHOULD instead determine the primary content of the entry from the hierarchy of child elements of atom:entry. As a third alternative, apply #1 above but apply it to atom:content children of atom:content (Subcontent constructs), and instead of #2, remove from the spec the allowance of multiple atom:content elements as children of atom:entry and require all instances of multiple atom:content elements to be under the "multipart/alternative"-typed atom:content element of atom:entry. Jon _____ From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon Davis Sent: Friday, October 01, 2004 7:55 PM To: atom-syntax@imc.org Subject: Default atom:content item I'm new on this list (since months ago), so perhaps this was discussed before. Looking at v0.3, I see that an atom:entry element may contain more than one atom:content element. A content element in an entry element can also contain one or more content elements (/feed/entry/content/content++). I like this, as it allows for attachments and such. But if an atom:entry element can contain more than one child atom:content nodes (/feed/entry/content++), one of those content elements should be marked as a "default" or "master" item, which would normally the XHTML representation of the item. In my implementation, I am going to either watch for a "default" attribute with a value of true, or if that isn't found I will use the first item in the list. This will allow my implementation to be "backwards compatible" with those flawed implementations out there that I've found that DO NOT recognize that more than one atom:content element can be used, as well as give me and users of my implementation to have a fallback mechanism that presumes a single content entry. - Jon Davis ------=_NextPart_000_00E4_01C4A804.5C8E1F10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
The "third alternative" is far more limiting = than the=20 "second alternative", as it would disallow distinctive attachments of = the same=20 type. Ignore it.
 
Jon

From: Jon Davis = [mailto:jon@accentra.net]=20
Sent: Friday, October 01, 2004 10:11 PM
To:=20 'atom-syntax@imc.org'
Subject: RE: Default atom:content=20 item

>
>> if = an atom:entry=20 element can contain more than one child atom:content
>> = nodes=20 (/feed/entry/content++), one of those content elements should =
>> be = marked as a=20 "default" or "master" item, which would normally the
>> = XHTML=20 representation of the item.
>> I = am going to=20 either watch for a "default" attribute with a value of true, =
>> or = if that isn't=20 found I will use the first item in the list.
 
 
> I am implementing with the = default=20 attribute as described in the original
> post of this thread until = this group=20 comes up with a better mechanism.
 
 
(While implementing I have noticed that the = Content=20 construct has two variants: one in which Content construct child = elements ARE=20 allowed, and one in which Content construct child elements are = explicitly=20 DISALLOWED. For purposes of discussion, I would like to refer to the = latter=20 variant as a Subcontent = construct.)
 
A content defaulting mechanism actually is = suggested in the=20 draft:
 
>>
Consumers SHOULD look at all
   alternative = content=20 elements and determine which one is most
   suitable, based = on=20 which @type and @mode the consumer supports, and
   = preferences=20 specified by the end user (if any).
<<
 
However, there is nothing in the specification = that=20 indicates that there should only be one atom:content of a = particular @type=20 / @mode.
 
That said, the file type based mechanism is = acceptable as=20 an alternative to a "default" attribute if two new=20 rules are added to the entry element:
 
1. The atom:entry MAY contain more than = one=20 atom:content elements IF each atom:content element has a unique @type = / @mode=20 pair.
2. Readers SHOULD NOT refer to any individual = atom:content=20 child element of an atom:content element marked as=20 "multipart/alternative" as the the primary content of the entry. Readers = SHOULD=20 instead determine the primary content of the entry from the hierarchy of = child=20 elements of atom:entry.
 
As a third alternative, apply #1 above but = apply it to=20 atom:content children of atom:content (Subcontent constructs), and = instead of=20 #2, remove from the spec the allowance of multiple = atom:content=20 elements as children of atom:entry and require all instances of multiple = atom:content elements to be under the "multipart/alternative"-typed = atom:content=20 element of atom:entry.
 
Jon
 

From: owner-atom-syntax@mail.imc.org = [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon=20 Davis
Sent: Friday, October 01, 2004 7:55 PM
To:=20 atom-syntax@imc.org
Subject: Default atom:content=20 item

I'm = new on this list=20 (since months ago), so perhaps this was discussed = before.
 
Looking at v0.3, I=20 see that an atom:entry element may contain more than one atom:content = element. A=20 content element in an entry element can also contain one or more content = elements (/feed/entry/content/content++). I like this, as it allows for=20 attachments and such.
 
But if = an atom:entry=20 element can contain more than one child atom:content nodes=20 (/feed/entry/content++), one of those content elements should be = marked as=20 a "default" or "master" item, which would normally the XHTML = representation of=20 the item.
 
In=20 my implementation, I am going to either watch for a "default" = attribute=20 with a value of true, or if that isn't found I will use the first item = in the=20 list. This will allow my implementation to be "backwards compatible" = with those=20 flawed implementations out there that I've found that DO NOT = recognize=20 that more than one atom:content element can be used, as well as give me = and=20 users of my implementation to have a fallback mechanism that presumes a = single=20 content entry.
 
- Jon=20 Davis
 
------=_NextPart_000_00E4_01C4A804.5C8E1F10-- From owner-atom-syntax@mail.imc.org Sat Oct 2 01:58: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 BAA12332 for ; Sat, 2 Oct 2004 01:58: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 i925o06T004714; Fri, 1 Oct 2004 22:50:00 -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 i925o0dH004713; Fri, 1 Oct 2004 22:50:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i925o03i004701 for ; Fri, 1 Oct 2004 22:50:00 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020550.i925o03i004701@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Fri, 01 Oct 2004 22:52:00 -0700 From: "Jon Davis" To: "'Jon Davis'" , Subject: RE: Default atom:content item Date: Fri, 1 Oct 2004 22:49:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010C_01C4A808.F540DCD0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <200410020511.i925B2eb086631@above.proper.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoKyQx2+r8909aRNG35szw8AsomwAD8VaAAAIgcGA= Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C4A808.F540DCD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >> That said, the file type based mechanism is acceptable as an alternative to a "default" attribute if two new rules are added to the entry element: 1. The atom:entry MAY contain more than one atom:content elements IF each atom:content element has a unique @type / @mode pair. 2. Readers SHOULD NOT refer to any individual atom:content child element of an atom:content element marked as "multipart/alternative" as the the primary content of the entry. Readers SHOULD instead determine the primary content of the entry from the hierarchy of child elements of atom:entry. << After further thought, as a reader implementer I could care less about the @mode. If two of the same @type are offered, regardless of @mode, I will be confused. Change the above from "unique @type / @mode pair" to just "unique @type". Jon _____ From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon Davis Sent: Friday, October 01, 2004 10:11 PM To: atom-syntax@imc.org Subject: RE: Default atom:content item > >> if an atom:entry element can contain more than one child atom:content >> nodes (/feed/entry/content++), one of those content elements should >> be marked as a "default" or "master" item, which would normally the >> XHTML representation of the item. >> I am going to either watch for a "default" attribute with a value of true, >> or if that isn't found I will use the first item in the list. > I am implementing with the default attribute as described in the original > post of this thread until this group comes up with a better mechanism. (While implementing I have noticed that the Content construct has two variants: one in which Content construct child elements ARE allowed, and one in which Content construct child elements are explicitly DISALLOWED. For purposes of discussion, I would like to refer to the latter variant as a Subcontent construct.) A content defaulting mechanism actually is suggested in the draft: >> Consumers SHOULD look at all alternative content elements and determine which one is most suitable, based on which @type and @mode the consumer supports, and preferences specified by the end user (if any). << However, there is nothing in the specification that indicates that there should only be one atom:content of a particular @type / @mode. That said, the file type based mechanism is acceptable as an alternative to a "default" attribute if two new rules are added to the entry element: 1. The atom:entry MAY contain more than one atom:content elements IF each atom:content element has a unique @type / @mode pair. 2. Readers SHOULD NOT refer to any individual atom:content child element of an atom:content element marked as "multipart/alternative" as the the primary content of the entry. Readers SHOULD instead determine the primary content of the entry from the hierarchy of child elements of atom:entry. As a third alternative, apply #1 above but apply it to atom:content children of atom:content (Subcontent constructs), and instead of #2, remove from the spec the allowance of multiple atom:content elements as children of atom:entry and require all instances of multiple atom:content elements to be under the "multipart/alternative"-typed atom:content element of atom:entry. Jon _____ From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon Davis Sent: Friday, October 01, 2004 7:55 PM To: atom-syntax@imc.org Subject: Default atom:content item I'm new on this list (since months ago), so perhaps this was discussed before. Looking at v0.3, I see that an atom:entry element may contain more than one atom:content element. A content element in an entry element can also contain one or more content elements (/feed/entry/content/content++). I like this, as it allows for attachments and such. But if an atom:entry element can contain more than one child atom:content nodes (/feed/entry/content++), one of those content elements should be marked as a "default" or "master" item, which would normally the XHTML representation of the item. In my implementation, I am going to either watch for a "default" attribute with a value of true, or if that isn't found I will use the first item in the list. This will allow my implementation to be "backwards compatible" with those flawed implementations out there that I've found that DO NOT recognize that more than one atom:content element can be used, as well as give me and users of my implementation to have a fallback mechanism that presumes a single content entry. - Jon Davis ------=_NextPart_000_010C_01C4A808.F540DCD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

>>

That said, the file type based = mechanism is=20 acceptable as an alternative to a "default" attribute if two new rules = are=20 added to the entry element:

1. The atom:entry MAY contain more than = one=20 atom:content elements IF each atom:content element has a unique @type = / @mode=20 pair.

2. Readers SHOULD NOT refer to any = individual=20 atom:content child element of an atom:content element marked as=20 "multipart/alternative" as the the primary content of the entry. = Readers=20 SHOULD instead determine the primary content of the entry from the = hierarchy=20 of child elements of atom:entry.

<<

After further thought, as a reader = implementer=20 I could care less about the @mode. If two of the same @type are = offered, regardless of @mode, I will be = confused. Change the above from "unique @type / @mode = pair" to=20 just "unique @type".

Jon


From: owner-atom-syntax@mail.imc.org = [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon=20 Davis
Sent: Friday, October 01, 2004 10:11 PM
To:=20 atom-syntax@imc.org
Subject: RE: Default atom:content=20 item

>
>> if = an atom:entry=20 element can contain more than one child atom:content
>> = nodes=20 (/feed/entry/content++), one of those content elements should =
>> be = marked as a=20 "default" or "master" item, which would normally the
>> = XHTML=20 representation of the item.
>> I = am going to=20 either watch for a "default" attribute with a value of true, =
>> or = if that isn't=20 found I will use the first item in the list.
 
 
> I am implementing with the = default=20 attribute as described in the original
> post of this thread until = this group=20 comes up with a better mechanism.
 
 
(While implementing I have noticed that the = Content=20 construct has two variants: one in which Content construct child = elements ARE=20 allowed, and one in which Content construct child elements are = explicitly=20 DISALLOWED. For purposes of discussion, I would like to refer to the = latter=20 variant as a Subcontent = construct.)
 
A content defaulting mechanism actually is = suggested in the=20 draft:
 
>>
Consumers SHOULD look at all
   alternative = content=20 elements and determine which one is most
   suitable, based = on=20 which @type and @mode the consumer supports, and
   = preferences=20 specified by the end user (if any).
<<
 
However, there is nothing in the specification = that=20 indicates that there should only be one atom:content of a = particular @type=20 / @mode.
 
That said, the file type based mechanism is = acceptable as=20 an alternative to a "default" attribute if two new=20 rules are added to the entry element:
 
1. The atom:entry MAY contain more than = one=20 atom:content elements IF each atom:content element has a unique @type = / @mode=20 pair.
2. Readers SHOULD NOT refer to any individual = atom:content=20 child element of an atom:content element marked as=20 "multipart/alternative" as the the primary content of the entry. Readers = SHOULD=20 instead determine the primary content of the entry from the hierarchy of = child=20 elements of atom:entry.
 
As a third alternative, apply #1 above but = apply it to=20 atom:content children of atom:content (Subcontent constructs), and = instead of=20 #2, remove from the spec the allowance of multiple = atom:content=20 elements as children of atom:entry and require all instances of multiple = atom:content elements to be under the "multipart/alternative"-typed = atom:content=20 element of atom:entry.
 
Jon
 

From: owner-atom-syntax@mail.imc.org = [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon=20 Davis
Sent: Friday, October 01, 2004 7:55 PM
To:=20 atom-syntax@imc.org
Subject: Default atom:content=20 item

I'm = new on this list=20 (since months ago), so perhaps this was discussed = before.
 
Looking at v0.3, I=20 see that an atom:entry element may contain more than one atom:content = element. A=20 content element in an entry element can also contain one or more content = elements (/feed/entry/content/content++). I like this, as it allows for=20 attachments and such.
 
But if = an atom:entry=20 element can contain more than one child atom:content nodes=20 (/feed/entry/content++), one of those content elements should be = marked as=20 a "default" or "master" item, which would normally the XHTML = representation of=20 the item.
 
In=20 my implementation, I am going to either watch for a "default" = attribute=20 with a value of true, or if that isn't found I will use the first item = in the=20 list. This will allow my implementation to be "backwards compatible" = with those=20 flawed implementations out there that I've found that DO NOT = recognize=20 that more than one atom:content element can be used, as well as give me = and=20 users of my implementation to have a fallback mechanism that presumes a = single=20 content entry.
 
- Jon=20 Davis
 
------=_NextPart_000_010C_01C4A808.F540DCD0-- From owner-atom-syntax@mail.imc.org Sat Oct 2 04:24:38 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 EAA03416 for ; Sat, 2 Oct 2004 04:24:38 -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 i928EIZY055332; Sat, 2 Oct 2004 01:14: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 i928EIZa055331; Sat, 2 Oct 2004 01:14:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i928EHZs055172 for ; Sat, 2 Oct 2004 01:14:18 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 2 Oct 2004 18:13:46 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 02 Oct 2004 18:13:45 +1000 Subject: Re: Default atom:content item From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200410020550.i925o03i004701@above.proper.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2/10/04 3:49 PM, "Jon Davis" wrote: > After further thought, as a reader implementer I could care less about the > @mode. If two of the same @type are offered, regardless of @mode, I will be > confused. Change the above from "unique @type / @mode pair" to just "unique > @type". So you disallow the possibility of a feed containing both a French and an English variation with the same @type? ... ... there are some institutions which want to, or for that matter are required to, publish dual language resources. e. From owner-atom-syntax@mail.imc.org Sat Oct 2 04:46: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 EAA04314 for ; Sat, 2 Oct 2004 04:46:08 -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 i928djxc063108; Sat, 2 Oct 2004 01:39:45 -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 i928djUa063107; Sat, 2 Oct 2004 01:39:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i928dj1O063097 for ; Sat, 2 Oct 2004 01:39:45 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020839.i928dj1O063097@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 01:41:03 -0700 From: "Jon Davis" To: Subject: Labeling of atom:content elements Date: Sat, 2 Oct 2004 01:39:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014D_01C4A820.9B9ACD90" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoW0aDPkny8zVGQ1uonx4dt1cjlA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_014D_01C4A820.9B9ACD90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know this was debated but it seems clear that this is still broken and unaddressed. If atom:content is to be of more use than formatting and language options, then the atom:content elements that are NOT themselves of type "multipart/alternate" (i.e. the children of the "multipart/alternate" element) MUST be named with a text string as an attribute, or else they are useless. This is not to be construed to be a distinct ID, but as a human-readable filename where duplicates are allowed. Imagine Atom being used in a similar method as an e-mail document. Atom supports MIME-typed attachments, but does not support named MIME-typed attachments. It doesn't make sense. An e-mail document is perceived as an entry in much the same way as an Atom entry is viewed, but e-mail attachments (Word documents, PDF documents, etc.) can be saved to the hard drive without trouble. Same with NNTP messages; Outlook Express know to hide the HTML/text formatting-alternative versions from the attachments list while displaying everything else. You guys know this. Why on EARTH does the draft still require implementors to depend entirely on indexing and user intervention for content naming? Jon ------=_NextPart_000_014D_01C4A820.9B9ACD90 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I know = this was=20 debated but it seems clear that this is still broken and unaddressed. If = atom:content is to be of more use than formatting and language options, = then the=20 atom:content elements that are NOT themselves of type = "multipart/alternate"=20 (i.e. the children of the "multipart/alternate" element) MUST be = named with=20 a text string as an attribute, or else they are useless. This is not to = be=20 construed to be a distinct ID, but as a human-readable filename where = duplicates=20 are allowed.
 
Imagine Atom being=20 used in a similar method as an e-mail document. Atom supports MIME-typed = attachments, but does not support named MIME-typed attachments. It = doesn't make=20 sense. An e-mail document is perceived as an entry in much the same way = as an=20 Atom entry is viewed, but e-mail attachments (Word documents, PDF = documents,=20 etc.) can be saved to the hard drive without trouble. Same with NNTP = messages;=20 Outlook Express know to hide the HTML/text formatting-alternative = versions from=20 the attachments list while displaying everything else. You guys know = this. Why=20 on EARTH does the draft still require implementors to depend entirely on = indexing and user intervention for content naming?
 
Jon
------=_NextPart_000_014D_01C4A820.9B9ACD90-- From owner-atom-syntax@mail.imc.org Sat Oct 2 04:56:11 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 EAA04776 for ; Sat, 2 Oct 2004 04:56:10 -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 i928lhfU065605; Sat, 2 Oct 2004 01:47:43 -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 i928lhjm065604; Sat, 2 Oct 2004 01:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i928lga8065594 for ; Sat, 2 Oct 2004 01:47:43 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020847.i928lga8065594@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 01:49:02 -0700 From: "Jon Davis" To: "'Atom Syntax'" Subject: RE: Default atom:content item Date: Sat, 2 Oct 2004 01:47:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoWIJONbZSXUL6R5eDA6o4vkI6HQAA9k8A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>> 2. Readers SHOULD NOT refer to any individual atom:content child >>> element of an atom:content element marked as "multipart/alternative" >>> as the the primary content of the entry. Readers SHOULD instead >>> determine the primary content of the entry from the hierarchy of child elements of atom:entry. > > The atom-format spec should not be dictating behaviour of things that > consume or produce feeds. It exists to specify the format, and what is > legal/error in that format. I disagree, for the reason I explained at the start. Consider someone using an Atom implementation producing an Entry with a primary formatting of XHTML, an ASCII alternative, and an attached Word document that should be treated as an attachment rather than as the primary Entry content. There needs to be some identification of content that is associated in purpose with the actual post (i.e. HTML and ASCII formats of the same content) and of content that is distinct in purpose from the actual post (Word document attachment containing ADDITIONAL information, etc.) In the current model, anything goes, nothing is labeled, nothing is identified as the primary content. This is unacceptable. There are ways of resolving this. - Identify the primary content as "primary content" (i.e. a "primary" or "default" attribute with a value of true) - Place content that is NOT to be treated as "primary content" in a separate "bag" (a separate element, such as an atom:attachments node). - Specify in the specification that content elements distinct from the "primary content" (attached files) should not be used, but rather the author should anticipate that all atom:content elements will be treated as identical in purpose, varying only in formatting or language. But it's broken as-is. Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Eric Scheid Sent: Saturday, October 02, 2004 1:14 AM To: Atom Syntax Subject: Re: Default atom:content item On 2/10/04 3:49 PM, "Jon Davis" wrote: > After further thought, as a reader implementer I could care less about > the @mode. If two of the same @type are offered, regardless of @mode, > I will be confused. Change the above from "unique @type / @mode pair" > to just "unique @type". So you disallow the possibility of a feed containing both a French and an English variation with the same @type? ... ... there are some institutions which want to, or for that matter are required to, publish dual language resources. e. From owner-atom-syntax@mail.imc.org Sat Oct 2 05: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 FAA06200 for ; Sat, 2 Oct 2004 05:20:32 -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 i929DmnT074076; Sat, 2 Oct 2004 02:13: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 i929DmoX074075; Sat, 2 Oct 2004 02:13:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i929DlbW074066 for ; Sat, 2 Oct 2004 02:13:47 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020913.i929DlbW074066@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 02:15:12 -0700 From: "Jon Davis" To: "'Atom Syntax'" Subject: RE: Default atom:content item Date: Sat, 2 Oct 2004 02:13:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoXYkr2nfAQpFFQVO8exaWaSksOAAAitsw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > ok, your basic premise is flawed: multipart/related is not supported, > only multipart/alternative, and so that word document shouldn't be there. > > if you want to provide material which are not *alternatives* to the > content but are related somehow to the entry, then use the > element, which includes not only an attribute for describing the > relationship in question in a machine-readable form, but also a human- > readable title attribute. Understand that I would prefer NOT to have distinct attachments (re: your reference to ). Meanwhile I'm trying to implement a reader where multiple atom:content elements are allowed, without requiring an atom:content[type="multipart/alternative"] parent, so atom:content elements can be treated as distinct attachments. This is the equivalent of multipart/mixed, unless we can remove the allowability of multiple atom:content elements directly under atom:entry (but allow multiple atom:content elements under an atom:content[type="multipart/alternative"] parent). >> - Specify in the specification that content elements distinct from the >> "primary content" (attached files) should not be used, but rather the >> author should anticipate that all atom:content elements will be >> treated as identical in purpose, varying only in formatting or language. > > I thought the language around 'multipart/alternative' described that behaviour. Perhaps it would if only atom:entry didn't support multiple atom:content elements without an atom:content[type="multipart/alternative"] parent! Jon -----Original Message----- From: Eric Scheid [mailto:eric.scheid@ironclad.net.au] Sent: Saturday, October 02, 2004 1:54 AM To: Jon Davis Subject: Re: Default atom:content item On 2/10/04 6:45 PM, "Jon Davis" wrote: > I disagree, for the reason I explained at the start. Consider someone > using an Atom implementation producing an Entry with a primary > formatting of XHTML, an ASCII alternative, and an attached Word > document that should be treated as an attachment rather than as the primary Entry content. ok, your basic premise is flawed: multipart/related is not supported, only multipart/alternative, and so that word document shouldn't be there. if you want to provide material which are not *alternatives* to the content but are related somehow to the entry, then use the element, which includes not only an attribute for describing the relationship in question in a machine-readable form, but also a human-readable title attribute. > - Specify in the specification that content elements distinct from the > "primary content" (attached files) should not be used, but rather the > author should anticipate that all atom:content elements will be > treated as identical in purpose, varying only in formatting or language. I thought the language around 'multipart/alternative' described that behaviour. e. From owner-atom-syntax@mail.imc.org Sat Oct 2 05:38: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 FAA07140 for ; Sat, 2 Oct 2004 05:38: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 i929T9Sl079537; Sat, 2 Oct 2004 02:29:09 -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 i929T9Tv079536; Sat, 2 Oct 2004 02:29:09 -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 i929T84k079450 for ; Sat, 2 Oct 2004 02:29:09 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id CCCC37C1EE; Sat, 2 Oct 2004 12:18:18 +0200 (CEST) To: "Sam Ruby" Cc: Atom-Syntax Subject: Re: Type for content References: <415D84EA.9070308@intertwingly.net> <20F7BD75-13CB-11D9-8EE5-000A95A51C9E@sun.com> <415D8F30.6020306@intertwingly.net> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sat, 02 Oct 2004 11:32:02 +0200 In-Reply-To: <415D8F30.6020306@intertwingly.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 01 Oct 2004 13:09:04 -0400, Sam Ruby wrote: > I prefer it RC3 were rolled in, and the door were left open for new > Paces to modify this. I'm +1 on this. The «leave door open for modification» part is especially important. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 2 05:40:50 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 FAA07188 for ; Sat, 2 Oct 2004 05:40:49 -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 i929Z9LY081815; Sat, 2 Oct 2004 02:35:09 -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 i929Z9Bx081810; Sat, 2 Oct 2004 02:35:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i929Z9UW081800 for ; Sat, 2 Oct 2004 02:35:09 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410020935.i929Z9UW081800@above.proper.com> Received: from dilithium ([65.124.36.204]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 02:36:38 -0700 From: "Jon Davis" To: "'Atom Syntax'" Subject: RE: Default atom:content item Date: Sat, 2 Oct 2004 02:34:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <200410020913.i929DlbW074066@above.proper.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSoXYkr2nfAQpFFQVO8exaWaSksOAAAitswAABjRuA= Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry for the flood of posts, hopefully this is my final post with one last question (or set of questions, rather). Eric was correct that my premise was incorrect; I had forgotten the meaning of "multipart/alternative", mistaking it for the meaning of "multipart/related". Do I understand correctly that all atom:content elements should be treated as multipart/related unless they are under an atom:content[type="multipart/alternative"] parent? If this is what was intended by the specification, is there any possiblity that an elaboration can be made as such? Essentially, what I was indicating previously applies, but with the roles of atom:entry and atom:content[@type="multipart/alternative"] reversed: 1. An atom:content element MAY contain more than one atom:content elements IF the @type attribute is "multipart/alternative" AND each child atom:content element is an alternative format of the content. 2. When multiple atom:content elements exist, readers SHOULD NOT refer to any individual atom:content child element of an atom:entry element as alternative content elements of the primary content of the entry. Readers SHOULD instead determine the primary content of the entry from the hierarchy of the atom:content children of atom:content elements marked as "multipart/alternative". If this is NOT what was intended by the specification, could someone please explain whether ALL atom:content elements are multipart/alternative, regardless of position (under atom:entry or under atom:content), and if so, why are there two ways of listing multiple atom:content items (one way being under atom:entry and one way being under atom:content[type="multipart/alternative"] elements)? Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jon Davis Sent: Saturday, October 02, 2004 2:13 AM To: 'Atom Syntax' Subject: RE: Default atom:content item > ok, your basic premise is flawed: multipart/related is not supported, > only multipart/alternative, and so that word document shouldn't be there. > > if you want to provide material which are not *alternatives* to the > content but are related somehow to the entry, then use the > element, which includes not only an attribute for describing the > relationship in question in a machine-readable form, but also a human- > readable title attribute. Understand that I would prefer NOT to have distinct attachments (re: your reference to ). Meanwhile I'm trying to implement a reader where multiple atom:content elements are allowed, without requiring an atom:content[type="multipart/alternative"] parent, so atom:content elements can be treated as distinct attachments. This is the equivalent of multipart/mixed, unless we can remove the allowability of multiple atom:content elements directly under atom:entry (but allow multiple atom:content elements under an atom:content[type="multipart/alternative"] parent). >> - Specify in the specification that content elements distinct from >> the "primary content" (attached files) should not be used, but rather >> the author should anticipate that all atom:content elements will be >> treated as identical in purpose, varying only in formatting or language. > > I thought the language around 'multipart/alternative' described that behaviour. Perhaps it would if only atom:entry didn't support multiple atom:content elements without an atom:content[type="multipart/alternative"] parent! Jon -----Original Message----- From: Eric Scheid [mailto:eric.scheid@ironclad.net.au] Sent: Saturday, October 02, 2004 1:54 AM To: Jon Davis Subject: Re: Default atom:content item On 2/10/04 6:45 PM, "Jon Davis" wrote: > I disagree, for the reason I explained at the start. Consider someone > using an Atom implementation producing an Entry with a primary > formatting of XHTML, an ASCII alternative, and an attached Word > document that should be treated as an attachment rather than as the primary Entry content. ok, your basic premise is flawed: multipart/related is not supported, only multipart/alternative, and so that word document shouldn't be there. if you want to provide material which are not *alternatives* to the content but are related somehow to the entry, then use the element, which includes not only an attribute for describing the relationship in question in a machine-readable form, but also a human-readable title attribute. > - Specify in the specification that content elements distinct from the > "primary content" (attached files) should not be used, but rather the > author should anticipate that all atom:content elements will be > treated as identical in purpose, varying only in formatting or language. I thought the language around 'multipart/alternative' described that behaviour. e. From owner-atom-syntax@mail.imc.org Sat Oct 2 06:49:44 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 GAA09794 for ; Sat, 2 Oct 2004 06:49:43 -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 i92AgW3w006361; Sat, 2 Oct 2004 03:42: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 i92AgWL1006360; Sat, 2 Oct 2004 03:42:32 -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 i92AgV5S006347 for ; Sat, 2 Oct 2004 03:42:31 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i92AghDF006355; Sat, 2 Oct 2004 06:42:46 -0400 Message-ID: <415E8607.9020107@intertwingly.net> Date: Sat, 02 Oct 2004 06:42:15 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Davis CC: "'Atom Syntax'" Subject: Re: Default atom:content item References: <200410020935.i929Z9UW081800@above.proper.com> In-Reply-To: <200410020935.i929Z9UW081800@above.proper.com> 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 Jon Davis wrote: > > If this is what was intended by the specification, is there any possiblity > that an elaboration can be made as such? If you are asking if Atom 0.3 can be updated, this group has moved beyond that and has no plans on updating Atom 0.3. If you are asking if draft-ietf-atompub-format-02 can be updated, the answer is certainly: the way you make that happen is described here: http://www.intertwingly.net/wiki/pie/HowToGetInvolved . - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Oct 2 07:00:07 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 HAA10012 for ; Sat, 2 Oct 2004 07:00: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 i92ArcHv010744; Sat, 2 Oct 2004 03:53:38 -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 i92Arcjs010743; Sat, 2 Oct 2004 03:53:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.tfb.com [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92ArbLU010733 for ; Sat, 2 Oct 2004 03:53:37 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410021053.i92ArbLU010733@above.proper.com> Received: from dilithium ([70.214.181.144]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 03:55:21 -0700 From: "Jon Davis" To: "'Sam Ruby'" Cc: "'Atom Syntax'" Subject: RE: Default atom:content item Date: Sat, 2 Oct 2004 03:52:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 in-reply-to: <415E8607.9020107@intertwingly.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSobP7rJiIyRRzKSkGdhi/3qQkrSgAABBYQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> If this is what was intended by the specification, is there any >> possiblity that an elaboration can be made as such? Bad choice of words. What I meant was, "Would it make sense that an elaboration be made as such?", opening it up for discussion. > If you are asking if Atom 0.3 can be updated, this group has > moved beyond that and has no plans on updating Atom 0.3. I was referring to the current IETF draft spec. > If you are asking if draft-ietf-atompub-format-02 can be updated, > the answer is certainly: the way you make that happen is described > here: > http://www.intertwingly.net/wiki/pie/HowToGetInvolved > > - Sam Ruby Yes, and that URL points here. "If you want to propose a change to the specification, it's probably best to float the idea on the mailing list first." Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Sam Ruby Sent: Saturday, October 02, 2004 3:42 AM To: Jon Davis Cc: 'Atom Syntax' Subject: Re: Default atom:content item Jon Davis wrote: > > If this is what was intended by the specification, is there any > possiblity that an elaboration can be made as such? If you are asking if Atom 0.3 can be updated, this group has moved beyond that and has no plans on updating Atom 0.3. If you are asking if draft-ietf-atompub-format-02 can be updated, the answer is certainly: the way you make that happen is described here: http://www.intertwingly.net/wiki/pie/HowToGetInvolved . - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Oct 2 11:40: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 LAA23315 for ; Sat, 2 Oct 2004 11:40: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 i92FWRsw035100; Sat, 2 Oct 2004 08:32:27 -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 i92FWRfL035099; Sat, 2 Oct 2004 08:32:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92FWQbk035093 for ; Sat, 2 Oct 2004 08:32:26 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i92FWT53023015 for ; Sat, 2 Oct 2004 09:32:29 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Y00BWOR63FN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 02 Oct 2004 09:32:28 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4Y00C5SR63E1@mail.sun.net> for atom-syntax@imc.org; Sat, 02 Oct 2004 09:32:27 -0600 (MDT) Date: Sat, 02 Oct 2004 08:32:35 -0700 From: Tim Bray Subject: Re: Default atom:content item In-reply-to: <200410021053.i92ArbLU010733@above.proper.com> To: Jon Davis Cc: "'Sam Ruby'" , "'Atom Syntax'" Message-id: <489C1F36-1488-11D9-A6CA-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200410021053.i92ArbLU010733@above.proper.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 2, 2004, at 3:52 AM, Jon Davis wrote: > Yes, and that URL points here. "If you want to propose a change to the > specification, it's probably best to float the idea on the mailing list > first." Unfortunately, you've kind of come in in the middle of the discussion. One thing that might help would be to look at http://www.intertwingly.net/wiki/pie/AtomPubIssuesList - in particular there's a lot of discussion of PaceReformedContent3 at the moment. -Tim From owner-atom-syntax@mail.imc.org Sat Oct 2 11:40:38 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 LAA23334 for ; Sat, 2 Oct 2004 11:40:37 -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 i92FYYaU035182; Sat, 2 Oct 2004 08:34:38 -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 i92FYMjN035176; Sat, 2 Oct 2004 08:34:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92FYLDx035169 for ; Sat, 2 Oct 2004 08:34:22 -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 (sccrmhc11) with SMTP id <2004100215341801100k1fl9e>; Sat, 2 Oct 2004 15:34:19 +0000 Date: Sat, 2 Oct 2004 09:34:17 -0600 Subject: Re: Labeling of atom:content elements 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: <200410020839.i928dj1O063097@above.proper.com> Message-Id: <85C546F2-1488-11D9-A3E6-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 i92FYMDx035171 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, October 2, 2004, at 02:39 AM, Jon Davis wrote: > I know this was debated but it seems clear that this is still broken > and unaddressed. If atom:content is to be of more use than formatting > and language options, then the atom:content elements that are NOT > themselves of type "multipart/alternate" (i.e. the children of the > "multipart/alternate" element) MUST be named with a text string as an > attribute, or else they are useless. This is not to be construed to be > a distinct ID, but as a human-readable filename where duplicates are > allowed. >   > Imagine Atom being used in a similar method as an e-mail document. > Atom supports MIME-typed attachments, but does not support named > MIME-typed attachments. It doesn't make sense. An e-mail document is > perceived as an entry in much the same way as an Atom entry is viewed, > but e-mail attachments (Word documents, PDF documents, etc.) can be > saved to the hard drive without trouble. Same with NNTP messages; > Outlook Express know to hide the HTML/text formatting-alternative > versions from the attachments list while displaying everything else. > You guys know this. Why on EARTH does the draft still require > implementors to depend entirely on indexing and user intervention for > content naming? > http://www.intertwingly.net/wiki/pie/AtomPubIssuesList is a list of the proposals that have been made thus far, and indicates those that are currently under discussion, one of which is PaceNukeMultipart[1]. If I'm not mistaken, that proposal has strong support and little or no opposition, so the whole discussion of the current multipart/alternative mechanism is about to become moot. I'm also of the impression that there is support for disallowing more than one content element, as evidenced by the proposed change to section 5.10 in PaceReformedContent3[2], which is receiving broad support. Of course, it may be that after that proposal is accepted (assuming it is), there will be efforts to resurrect some sort of multiple content. I for one don't feel particularly strongly either way about whether to allow multiple language and format alternatives. I can imagine it being useful on the one hand, and I can imagine it adding complexity that very few people use on the other. But getting to what you're discussing--attachments--I think it would be better to have an element to be used specifically for attachments than to put attachments into multiple content elements and add attributes to identify the primary content and to name the attachments. There's also the question of whether attachments should be linked to or included inline. I think there are reasons for doing them either way under different circumstances, and even for distinguishing between secondary content that the publisher wants to suggest be rendered alongside the primary content, and secondary content that the publisher simply wants to link to (the link element being the appropriate mechanism for the latter). A few relevant proposals to give you an idea of what has been discussed (but not entirely resolved) already include PaceLinkPurpose[3], PaceExtensionNamespace[4] (the section on "Embed" constructs--not that I think this specific proposal will be adopted, nor as the author am I likely to support it anymore, though I'd still like to come up with a solution for the issue it addresses), and some that have been closed: PaceGraphicElement[5], PaceNonEntryResources[6] and PaceObjectModule[7]. Antone [1] http://www.intertwingly.net/wiki/pie/PaceNukeMultipart [2] http://www.intertwingly.net/wiki/pie/PaceReformedContent3 [3] http://www.intertwingly.net/wiki/pie/PaceLinkPurpose [4] http://www.intertwingly.net/wiki/pie/PaceExtensionNamespace [5] http://www.intertwingly.net/wiki/pie/PaceGraphicElement [6] http://www.intertwingly.net/wiki/pie/PaceNonEntryResources [7] http://www.intertwingly.net/wiki/pie/PaceObjectModule From owner-atom-syntax@mail.imc.org Sat Oct 2 16:45: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 QAA07205 for ; Sat, 2 Oct 2004 16:45: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 i92KXvgU052827; Sat, 2 Oct 2004 13:33: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 i92KXvZL052826; Sat, 2 Oct 2004 13:33: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 i92KXtKt052815 for ; Sat, 2 Oct 2004 13:33:56 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id B33207C1EE; Sat, 2 Oct 2004 23:23:04 +0200 (CEST) Date: Sat, 02 Oct 2004 22:36:52 +0200 To: "Jon Davis" Subject: Re: Default atom:content item Cc: Atom-Syntax References: <200410020254.i922sXaF076505@above.proper.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200410020254.i922sXaF076505@above.proper.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 1 Oct 2004 19:54:31 -0700, Jon Davis wrote: > In my implementation, I am going to either watch for a "default" > attribute If you're going to implement your own attributes in Atom, you would be wise in prefixing them with your own, home-grown namespace. If not, you're basically saying «this attribute belongs to Atom», although all attributes by default are non-namespaced. ... would therefore be totally fine. However, ... is not so okay. Imo, at least. Also, I would rather recommend you to implement a scoring attribute to be able to sort several elements. But this is your implementation, so you do what you want. But please try to keep your own elements and attributes in your own namespace. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 2 16:49:47 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 QAA07372 for ; Sat, 2 Oct 2004 16:49:47 -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 i92KhC9p053971; Sat, 2 Oct 2004 13:43: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 i92KhCeL053970; Sat, 2 Oct 2004 13:43:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.TFB.COM [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92KhC6k053964 for ; Sat, 2 Oct 2004 13:43:12 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410022043.i92KhC6k053964@above.proper.com> Received: from dilithium ([70.214.190.105]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 13:43:40 -0700 From: "Jon Davis" To: "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" Cc: "'Atom-Syntax'" Subject: RE: Default atom:content item Date: Sat, 2 Oct 2004 13:43:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSov6q9Kx2Z+0+WQCeToY7hRssxRgAAJkqQ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i92KhC6k053965 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The discussion of the "default" tag is moot since my awkward discovery of the purpose of "multipart/alternative". Jon -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Asbjørn Ulsberg Sent: Saturday, October 02, 2004 1:37 PM To: Jon Davis Cc: Atom-Syntax Subject: Re: Default atom:content item On Fri, 1 Oct 2004 19:54:31 -0700, Jon Davis wrote: > In my implementation, I am going to either watch for a "default" > attribute If you're going to implement your own attributes in Atom, you would be wise in prefixing them with your own, home-grown namespace. If not, you're basically saying «this attribute belongs to Atom», although all attributes by default are non-namespaced. ... would therefore be totally fine. However, ... is not so okay. Imo, at least. Also, I would rather recommend you to implement a scoring attribute to be able to sort several elements. But this is your implementation, so you do what you want. But please try to keep your own elements and attributes in your own namespace. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 2 17:19:16 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 RAA08626 for ; Sat, 2 Oct 2004 17:19:16 -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 i92LDh6b056494; Sat, 2 Oct 2004 14:13:43 -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 i92LDhAk056493; Sat, 2 Oct 2004 14:13:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from headsense.com (65-124-36-194.DSL.TFB.COM [65.124.36.194] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92LDgNp056487 for ; Sat, 2 Oct 2004 14:13:42 -0700 (PDT) (envelope-from jon@accentra.net) Message-Id: <200410022113.i92LDgNp056487@above.proper.com> Received: from dilithium ([70.214.190.105]) by headsense.com with MailEnable ESMTP; Sat, 02 Oct 2004 14:14:13 -0700 From: "Jon Davis" To: "'Atom Syntax'" Subject: Broken process (RE: Default atom:content item) Date: Sat, 2 Oct 2004 14:13:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <489C1F36-1488-11D9-A6CA-000A95A51C9E@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcSolVv7JsQM0dsqRfO27yPQyPtqrwAKxU1g Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Yes, and that URL points here. "If you want to propose a change to the >> specification, it's probably best to float the idea on the mailing >> list first." > > Unfortunately, you've kind of come in in the middle of the discussion. > One thing that might help would be to look at > http://www.intertwingly.net/wiki/pie/AtomPubIssuesList - in particular > there's a lot of discussion of PaceReformedContent3 at the moment. -Tim Thanks. *sigh* Wikis. They are powerful and handy, yes, .. But it's when from big-name domain names say things that feel like, "Where have you been? Don't you understand that it's all discussed here at http://www.interwingly.net/wiki/pie/SomeObscureWikiTopicThatOnlyThoseWhoHave BeenAroundForTwoYearsWouldEverKnowAnythingAbout" that makes me feel like the wiki-based system is powerful and seemingly sufficient, but nonetheless flawed because each topic / page is given almost equal priority in presentation. This process is also slow. Atom has been under construction for months, and the core of it is atom:content, which is as broken as it was months ago. I'm discontinuing my involvement here for a while, as quick as I showed up (note that I was paying close attention since the Echo days), partly for the benefit of all of you, not just because I feel bad for spamming the group with so many posts in one night and annoying all of you and also for not paying more attention to the wiki, but also because I feel like the PROCESS of developing Atom is broken (this comment having nothing to do with my participation herein). The wiki says to refer to the mailing list to discuss things. The mailing list says to refer to the wiki to discuss things. The wiki says to get approval from the mailing list before adding anything to the wiki. The mailing list says to get approval from the wiki before adding anything to the mailing list. Meanwhile, scanning the discussions, words go around in terms of uber-knowledge and uber-education that really simply don't apply in real-world implementation except as philosophical technical studies, and meanwhile very little gets done in one year. You guys need to delegate some individuals to take authoritative ownership of certain parts of Atom, to make a decision about things, move forward, and open the floor for discussion of what happened rather than what to do next. Give authoritative ownership not just those who manage the wiki, mailing list, and spec draft write-up. Your current plan encourages knuckleheads like myself to jump in and slow things down. And perhaps those of you who are "high on the chain", whose voices are louder than others because of who you work for and because of your background, are enjoying some authority freely given to you by your peers, but the fact that I am technically a peer here gives me unease. I give Big Company M feedback like "I don't understand how this works and I think you should change it to such-and-such" all the time, but ultimately I trust that Big Company M has staff on hand who will ultimately make an educated decision even after hearing me that will probably be the right one. In the end, stuff gets done, and it's done in days or weeks, not months or years. This reminds me of the difference between a democracy and a republic. A democracy is "a government of the masses. Authority derived through mass meeting or any other form of "direct" expression. Results in mobocracy. Attitude toward property is communistic--negating property rights. Attitude toward law is that the will of the majority shall regulate, whether is be based upon deliberation or governed by passion, prejudice, and impulse, without restraint or regard to consequences. Results in demogogism, license, agitation, discontent, anarchy". Whereas, in a republic, "Authority is derived through the election by the people of public officials best fitted to represent them. Attitude toward law is the administration of justice in accord with fixed principles and established evidence, with a strict regard to consequences. A greater number of citizens and extent of territory may be brought within its compass. Avoids the dangerous extreme of either tyranny or mobocracy. Results in statesmanship, liberty, reason, justice, contentment, and progress. Is the "standard form" of government throughout the world. A republic is a form of government under a constitution which provides for the election of (1) an executive and (2) a legislative body, who working together in a representative capacity, have all the power of appointment, all power of legislation, all power to raise revenue and appropriate expenditures, and are required to create (3) a judiciary to pass upon the justice and legality of their government acts and to recognize (4) certain inherent individual rights. -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Tim Bray Sent: Saturday, October 02, 2004 8:33 AM To: Jon Davis Cc: 'Sam Ruby'; 'Atom Syntax' Subject: Re: Default atom:content item On Oct 2, 2004, at 3:52 AM, Jon Davis wrote: > Yes, and that URL points here. "If you want to propose a change to the > specification, it's probably best to float the idea on the mailing > list first." Unfortunately, you've kind of come in in the middle of the discussion. One thing that might help would be to look at http://www.intertwingly.net/wiki/pie/AtomPubIssuesList - in particular there's a lot of discussion of PaceReformedContent3 at the moment. -Tim From owner-atom-syntax@mail.imc.org Sat Oct 2 19:28: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 TAA15237 for ; Sat, 2 Oct 2004 19:28:13 -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 i92NLONa063555; Sat, 2 Oct 2004 16:21: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 i92NLOQ9063554; Sat, 2 Oct 2004 16:21:24 -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 i92NLNAj063542 for ; Sat, 2 Oct 2004 16:21:23 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id B99E97C1EE; Sun, 3 Oct 2004 02:10:36 +0200 (CEST) To: "Martin Duerst" , "Atom-Syntax Syntax" Subject: Re: PaceReformedContent3 References: <41911434.682581710@smtp.bjoern.hoehrmann.de> <2ACF97D7-1115-11D9-9C17-000A95A51C9E@sun.com> <41911434.682581710@smtp.bjoern.hoehrmann.de> <4.2.0.58.J.20040930082552.066a1440@localhost> Message-ID: Date: Sun, 03 Oct 2004 01:24: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: <4.2.0.58.J.20040930082552.066a1440@localhost> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 30 Sep 2004 08:35:52 +0900, Martin Duerst wrote: > I'd prefer somebody come up with a special escaping syntax that only > escapes the doctype part. We could even do this with something like: > XSLT does this already, and it works rather fine. It's done with the element's 'doctype-system' and 'doctype-public' attributes: Maybe Atom can adopt these attributes in the element? I would not oppose that, at least. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 2 19:37:48 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 TAA15646 for ; Sat, 2 Oct 2004 19:37:47 -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 i92NVo6u063942; Sat, 2 Oct 2004 16:31: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 i92NVoO3063941; Sat, 2 Oct 2004 16:31:50 -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 i92NVnbU063932 for ; Sat, 2 Oct 2004 16:31:49 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id DB7087C1EE; Sun, 3 Oct 2004 02:21:03 +0200 (CEST) To: "Martin Duerst" , "Tim Bray" Cc: "Atom-Syntax Syntax" Subject: Re: PaceReformedContent3 References: <4.2.0.58.J.20040929130431.066f0de0@localhost> <4.2.0.58.J.20040929084918.065308b0@localhost> <4.2.0.58.J.20040928164143.05654b30@localhost> <4.2.0.58.J.20040928164143.05654b30@localhost> <4.2.0.58.J.20040929084918.065308b0@localhost> <4.2.0.58.J.20040929130431.066f0de0@localhost> <4.2.0.58.J.20040930083637.06962f00@localhost> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sun, 03 Oct 2004 01:34:49 +0200 In-Reply-To: <4.2.0.58.J.20040930083637.06962f00@localhost> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 30 Sep 2004 08:39:29 +0900, Martin Duerst wrote: > So you are saying that type='TEXT/plain' or type="IMAGE/SVG+XML' are > legal, but type='html' or type='xhtml' aren't? Blech! > I have nothing against using different casing in the examples to make > the distinction clear, but I think it is an extremely bad idea to > have an attribute where some of the values are case-sensitive and > others are not. I agree entirely. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 2 19:46:42 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 TAA16300 for ; Sat, 2 Oct 2004 19:46:42 -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 i92NeO2n064791; Sat, 2 Oct 2004 16: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 i92NeOcT064790; Sat, 2 Oct 2004 16:40:24 -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 i92NeNNS064782 for ; Sat, 2 Oct 2004 16:40:24 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id A7F427C1EE; Sun, 3 Oct 2004 02:29:38 +0200 (CEST) Date: Sun, 03 Oct 2004 01:43:24 +0200 To: "Tim Bray" Subject: Re: PaceReformedContent3 Cc: Atom-Syntax References: <2ACF97D7-1115-11D9-9C17-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <2ACF97D7-1115-11D9-9C17-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 27 Sep 2004 23:10:59 -0700, Tim Bray wrote: > I just cooked this up, it embodies the "HTML"/"XHTML" notion, plus > incorporating comments from Martin and Graham. I don't like the overloading of @type. I think MIME types should go all the way, but I don't mind it so much that I'll halt consensus over it. What I don't understand is the 'TEXT' type. How does this differ from 'text/plain'? At least, with 'text/plain', you can add MIME type parameters, while I guess this is disallowed for 'TEXT'. Am I correct? What do we gain by using the four uppercase letters 'TEXT' from using the MIME type 'text/plain' (optionally with parameters)? As a side-note, I'd like to mention again my idea of grouping popular MIME types within the four content modes mentioned in this pace. The four modes are: - Escaped markup - XML - Plain text - Base64-encoded content I'd like to see ordinary MIME types used, but grouped in this way in the specification: = Escaped markup = text/html = XML = */*+xml, */xml = Plain text = text/* (but not text/html) = Base64 = Pretty much everything else We could and should of course add more known MIME types on the way, but as we're moving in the «need to parse and check the @type attribute»-direction anyway, I don't see why we can't go all the way. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 2 20:11:47 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 UAA17470 for ; Sat, 2 Oct 2004 20:11:47 -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 i9304VGM066186; Sat, 2 Oct 2004 17:04:31 -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 i9304Vki066185; Sat, 2 Oct 2004 17:04:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9304V3c066171 for ; Sat, 2 Oct 2004 17:04:31 -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 (rwcrmhc13) with SMTP id <20041003000431015003a3vme>; Sun, 3 Oct 2004 00:04:31 +0000 Date: Sat, 2 Oct 2004 18:04:30 -0600 Subject: Re: PaceReformedContent3 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: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9304V3c066180 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, October 2, 2004, at 05:43 PM, Asbjørn Ulsberg wrote: > The four modes are: > - Escaped markup > - XML > - Plain text > - Base64-encoded content Is there a difference between the XML mode and the plain text mode? In either, anything that looks like markup but isn't (eg. you want the user to see , not to get blinking text) has to be escaped. Plain text can't contain actual markup, but that's a matter of the content type, not the mode. Antone P.S. Is there any way to search the mailing list archive? I find myself vaguely remembering things having been discussed before, but not knowing a quick way to find them. From owner-atom-syntax@mail.imc.org Sat Oct 2 20:44:36 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 UAA19523 for ; Sat, 2 Oct 2004 20:44: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 i930bum4068788; Sat, 2 Oct 2004 17:37: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 i930buDK068787; Sat, 2 Oct 2004 17:37:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i930bt8Q068776 for ; Sat, 2 Oct 2004 17:37:55 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041003003756.6917.qmail@web41213.mail.yahoo.com> Received: from [67.160.85.184] by web41213.mail.yahoo.com via HTTP; Sat, 02 Oct 2004 17:37:56 PDT Date: Sat, 2 Oct 2004 17:37:56 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: "Asbjørn" Ulsberg , Tim Bray Cc: Atom-Syntax In-Reply-To: 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: --- Asbjørn Ulsberg wrote: > > What I don't understand is the 'TEXT' type. How does > this differ from > 'text/plain'? At least, with 'text/plain', you can > add MIME type > parameters, while I guess this is disallowed for > 'TEXT'. Am I correct? (a) Content that is text/plain may contain characters that are not valid XML characters. Specifically a number of text/plain documents on the Web [such as IETF RFCs] contain form feed characters which are illegal in XML. (b) Using MIME type parameters is a lot of UNNECESSARY complexity to push on clients. > What do we gain by using the four uppercase letters > 'TEXT' from using the > MIME type 'text/plain' (optionally with parameters)? (a) Less ambiguity. (b) Less complexity for content producers and feed consumers. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Sat Oct 2 20:44:39 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 UAA19542 for ; Sat, 2 Oct 2004 20:44:38 -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 i930dU4C068848; Sat, 2 Oct 2004 17:39:30 -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 i930dUeo068847; Sat, 2 Oct 2004 17:39:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i930dTTZ068832 for ; Sat, 2 Oct 2004 17:39:29 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id RAA15257 for ; Sat, 2 Oct 2004 17:39:28 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id RAA19874 for ; Sat, 2 Oct 2004 17:39:27 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sat, 02 Oct 2004 17:39:27 -0700 Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i930dPlB027859 for ; Sat, 2 Oct 2004 17:39:26 -0700 (PDT) Date: Sat, 02 Oct 2004 17:39:27 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: PaceReformedContent3 Message-ID: <7267E470A08F90FB642E777F@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Saturday, October 2, 2004 6:04 PM -0600 Antone Roundy wrote: > > P.S. Is there any way to search the mailing list archive? I find > myself vaguely remembering things having been discussed before, but > not knowing a quick way to find them. On Yahoo or Google, you can use this: site:imc.org inurl:atom-syntax -intitle:"archive of" your query here Hint to the archive maintainer: add a robots meta tag with noindex to the index pages. Robots will still follow the links to the actual messages. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Oct 2 20:51: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 UAA19994 for ; Sat, 2 Oct 2004 20:51: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 i930eviH068913; Sat, 2 Oct 2004 17:40: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 i930evBk068912; Sat, 2 Oct 2004 17:40:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i930evWO068903 for ; Sat, 2 Oct 2004 17:40:57 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by mail.pubsub.com (Postfix) with ESMTP id 7F35EA4E063 for ; Sat, 2 Oct 2004 20:40:57 -0400 (EDT) Reply-To: From: "Bob Wyman" To: Subject: atom:id again... Please accept my apologies for doing this now... Date: Sat, 2 Oct 2004 20:40:43 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSo4Zw/LWgZEGuHSKiB6Mzmq0c2yg== Message-Id: <20041003004057.7F35EA4E063@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My apologies for bringing up atom:id again... I've got a problem that I'm trying to solve. Basically, what I want to do is publish an instance of a feed that has potentially many entries all with the same atom:id. However, I think it was decided that one shouldn't do this. (I've been digging through the list but can't find what I'm looking for.) Let me describe what I'm trying to do and please let me know what is the "right" thing. At PubSub.com, we publish "airport status alerts" via Atom files and via "Atom over XMPP PubSub". For instance, at the moment some sort of "Aircraft Emergency" is slowing down traffic at JFK by between 16 and 30 minutes and increasing... If you were planning to pick someone up at JFK tonight, it would be handy if you knew that there is a general delay going on. My assumption is that for most people, the only interesting information is going to be the current status. However, there are a number of applications that would require the ability to track changes in status over time. For those who only care about current status, we only need to have one entry for any airport in our feed -- the most recent one. For those who care about changes over time, we should provide access to all entries for some given time period (even entries that are now "old" and obsolete) so that they can be sure to pick up everything they need without gaps. What I would like to do is create a single tag: URI for each airport. I would then use that URI as the atom:id for any and every status record for that airport. Thus, "tag:pubsub.com,2004:JFK" might be the atom:id we would use for *all* JFK reports from now until the universe ends... Doing this would make it really easy for applications to handle "replacing" old entries. They would just make sure that they only had the most recent instance of any particular atom:id. On the other hand, for the folk that want history, I'd like to publish the last 10 alerts or even the last 24 hours of alerts to make it easier for them. (I assume that "good" aggregators would actually use RFC3229+feed and thus wouldn't actually get the history unless they needed it.) But, if I publish multiple entries in a single atom file and if each entry has the same atom:id, I think I'm breaking the rules. Is this the case? (Note: Please, let's not get into the "versions and variants" debate...) Or, is publishing multiple entries in a single instance of a feed simply the logical equivalent of publishing multiple entries in different instances of the feed over time? What is the correct way to handle this? Below, you'll see what we currently publish (either in a file or over XMPP) as an airport delay entry> I've inserted an atom:id for illustrative purposes. Imagine reading an atom file that contain 10 entries like the one below. Each entry would have the same atom:id but each entry would also have a different modified time (note: this is Atom 0.3 -- thus, updated isn't used.) bob wyman 2004-10-02:T19:18:43-0400 2004-10-02:T19:18:43-0400 tag:pubsub.com,2004:JFK Airport Status PubSub Airport Status Publisher 102 0 2004-10-02:T19:18:43-0400 AirportStatusUpdate JFK USA John F. Kennedy International Airport New York, NY 23 A/C EMERGENCY 30 3 Increasing Delay 16 From owner-atom-syntax@mail.imc.org Sat Oct 2 21:38: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 VAA22097 for ; Sat, 2 Oct 2004 21:38: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 i931WKPG071830; Sat, 2 Oct 2004 18:32: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 i931WKMF071829; Sat, 2 Oct 2004 18:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i931WJrF071822 for ; Sat, 2 Oct 2004 18:32:20 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i931WNlF006943; Sat, 2 Oct 2004 21:32:23 -0400 (EDT) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTP55571 (AUTH bob@wyman.us); Sat, 2 Oct 2004 21:32:21 -0400 (EDT) Message-Id: <200410030132.BTP55571@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , "'Tim Bray'" , "'Atom-Syntax Syntax'" Subject: RE: PaceReformedContent3 Date: Sat, 2 Oct 2004 21:32:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSmfMaF7pSIkvisQLmRDrSE/MLN/ACaeBdg In-reply-to: <20040929231256.228.qmail@web41206.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Quite frankly I think embedding XML directly in atom:content is > a non-scenario mostly introduced by geeks on this list than > something that most publishers or content producers intend to do. I guess I must be a geek... I'm definitely "on this list"... But, I'm also a publisher... Please see: http://www.imc.org/atom-syntax/mail-archive/msg10250.html In which I provide an example of XML that we are embedding in atom:content today. This works with Atom 0.3. How should I migrate this to Atom 1.0? Also, could you tell me how USGS should best migrate their existing Earthquake RSS feeds to Atom? Currently, they just use a few namespaced extension tags. But, instead of what they do today: See: http://earthquake.usgs.gov/recenteqsww/eqs1day-M2.5.xml it would be real nice if they could just insert one of the XML objects they normally produce directly in an Atom file. i.e. What I'd like to see is: 2004-10-02:T19:18:43-0400 2004-10-02:T19:18:43-0400 tag:example.com,2004:51147717 From owner-atom-syntax@mail.imc.org Sun Oct 3 19:15:13 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 TAA25999 for ; Sun, 3 Oct 2004 19:15:10 -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 i93KHrQ6051642; Sun, 3 Oct 2004 13:17: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 i93KHrTm051641; Sun, 3 Oct 2004 13:17:53 -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 i93KHqVq051633 for ; Sun, 3 Oct 2004 13:17:52 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao11.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041003201751.LKSN24786.lakermmtao11.cox.net@A31P>; Sun, 3 Oct 2004 16:17:51 -0400 From: "Scott Hollenbeck" To: "'Jon Davis'" , "'Atom Syntax'" Subject: RE: Broken process (RE: Default atom:content item) Date: Sun, 3 Oct 2004 16:17:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <200410022113.i92LDgNp056487@above.proper.com> Thread-Index: AcSolVv7JsQM0dsqRfO27yPQyPtqrwAKxU1gADFDWWA= Message-Id: <20041003201751.LKSN24786.lakermmtao11.cox.net@A31P> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > The wiki says to refer to the mailing list to discuss things. > The mailing list says to refer to the wiki to discuss things. > The wiki says to get approval from the mailing list before > adding anything to the wiki. The mailing list says to get > approval from the wiki before adding anything to the mailing > list. Meanwhile, scanning the discussions, words go around in > terms of uber-knowledge and uber-education that really simply > don't apply in real-world implementation except as > philosophical technical studies, and meanwhile very little > gets done in one year. For what it's worth the mailing list is the only authoritative discussion venue for an IETF working group. No external approval is required to participate in a discussion on the mailing list, either. I don't care if people collect their thoughts on a wiki, but if any decisions are made they need to be made and documented on this list. -Scott- (speaking as the area advisor for this WG) From owner-atom-syntax@mail.imc.org Sun Oct 3 19:15: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 TAA26017 for ; Sun, 3 Oct 2004 19:15: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 i93Jjs2s049630; Sun, 3 Oct 2004 12:45:54 -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 i93Jjsmw049629; Sun, 3 Oct 2004 12:45:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93Jjs29049622 for ; Sun, 3 Oct 2004 12:45:54 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i93JjilH016886; Sun, 3 Oct 2004 15:45:55 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTQ75407 (AUTH bob@wyman.us); Sun, 3 Oct 2004 15:45:44 -0400 (EDT) Message-Id: <200410031945.BTQ75407@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , , "'Tim Bray'" , "'Atom-Syntax Syntax'" Subject: RE: PaceReformedContent3 Date: Sun, 3 Oct 2004 15:45:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSpYKX9FIv05x8/R9GlyD1RcPgHxwAHxcnQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041003154959.80743.qmail@web41207.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > So do you really think I'm going to implement support for > executing arbitrary code due to directives in an RSS/Atom feed? > Thanks but no thanks. I paid attention during Security > month at Microsoft 2.5 years ago. LOL! It's cute to see someone from Microsoft try to lecture me on this subject when I generated much ill-will at Microsoft almost 13 years ago by warning them about precisely the issue of passing procedural code in their email and office systems. (Note: This issue was well-known to us as far back as 1981 when we were building ALL-IN-1, the office automation system that I was responsible for at Digital and which, along with Lotus Notes, -- whose predecessor NewNotes, I had built -- was the model for Microsoft Office and Microsoft Applications programmability in general.) In any case, I think you're overreacting. Absent bugs in the code, XSL Templates can be considered safe as long as you don't permit external functions to be called. A key idea behind much of what we've been doing the last couple decades has been the separation of the presentation of objects from their on-the-wire encoding. XSL Templates, CSS Style sheets, etc. are all part of that effort and those of us who pay attention, and have been paying attention, know how to handle them safely. In any case, any aggregator which is incapable or unwilling to process XSL Templates should simply ignore content that requires that the things be used. Users will find the tools that address their needs best -- and safely. bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 3 19:15: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 TAA26032 for ; Sun, 3 Oct 2004 19:15: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 i93KNHTP052056; Sun, 3 Oct 2004 13:23:17 -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 i93KNH9c052055; Sun, 3 Oct 2004 13:23:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93KNH0m052043 for ; Sun, 3 Oct 2004 13:23:17 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id EF383A4E1DA; Sun, 3 Oct 2004 16:23:15 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Atom-Syntax Syntax'" Subject: PaceIdConstruct2 Date: Sun, 3 Oct 2004 16:23:23 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSphtS2r39NDBT0RCSUCmm1vwRdlQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20041003202315.EF383A4E1DA@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: Whenever a resource appears in an Atom Document, its identifier SHOULD be the same as any other times it has appeared in an Atom Document, and MUST NOT be the same as the identifier currently or formerly used for any other Atom resource. Changes to the content or location of the resource MUST NOT change the identifier. This wording does not prohibit multiple instances of a single resource appearing within a single Atom Document. It does, however, require that if multiple instances of a single resource do appear in a single document, then all such instances MUST have the same identifier. As I read this, it tells me that if -- as a publisher -- I maintain a resource which is: "The delay status at JFK airport", then all instances of that resource MUST have the same atom:id even if two or more such instances appear in a single Atom Document. This is, of course, consistent with a view that says that an Atom Document is simply a sliding window on a potentially infinitely long "feed" of atom entries. While the window at any time may contain fewer entry instances then have been published to the feed, if the window where expanded to match the "size" of the feed itself, then all instances of all entries that had been published to the feed over time would become visible. Thus, the maximal[1] Atom Document might contain multiple instances of some resources, all of which would share a common atom:id. Given that the maximal Atom Document might contain multiple instances of a single atom:id, it appears to me reasonable that a less-then-maximal instance of an Atom Document might also contain such multiple instances. This "sliding window" view is, of course, the view that is maintained by most aggregators. Their model of the feed contains not only those entries which are most recently available in the Atom Document but also all those entries that had been visible in the past. While for many purposes, we can anticipate that aggregators will discard "old" entries that have the same atom:id as newer entries, this behavior does not satisfy all requirements and should not be considered a requirement. This discussion is, of course, one of the things that I was arguing some months back should be covered by the "BAG" Blog Architecture Group... Atom will be underspecified if we don't clearly define what a "feed" is and how an Atom Document relates to a feed. PaceIdConstruct 2 says further: A system that accepts input in Atom format that it subsequently outputs in Atom format SHOULD pass through the values of all identifiers. This would seem to require that systems such as PubSub.com's, which create Atom format feeds based on Atom format inputs, would be required to pass atom:id's unchanged into the generated aggregate feeds. Given this requirement, it would appear that we would also need a requirement that says that atom:id's must be globally unique over all feeds and for all time. This degree of uniqueness is necessary to ensure that identifier clashes do not occur when multiple input sources are aggregated. If atom:id's are not required to be universally unique (and in time) then it becomes virtually impossible for an aggregator to safely do what PaceIDConstruct says that it "SHOULD" since there will be considerable risk that in passing through values unchanged, the aggregator will cause multiple resources to share a single atom:id. bob wyman [1] http://www.webster-dictionary.org/definition/maximal maximal - the greatest or most complete From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19:04 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 TAA26276 for ; Sun, 3 Oct 2004 19:19: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 i93HF912040327; Sun, 3 Oct 2004 10:15:09 -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 i93HF9aN040325; Sun, 3 Oct 2004 10:15:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93HF9Rq040313; Sun, 3 Oct 2004 10:15:09 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail09-en1 [10.13.10.98]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i93HFBOo013488; Sun, 3 Oct 2004 10:15:11 -0700 (PDT) Received: from webmail09 (localhost [127.0.0.1]) by mac.com (Xserve/webmail09/MantshX 4.0) with ESMTP id i93HFA5P016222; Sun, 3 Oct 2004 10:15:11 -0700 (PDT) Message-ID: <8284336.1096823710795.JavaMail.dtcd@mac.com> Date: Sun, 03 Oct 2004 10:15:10 -0700 From: Graham Parks To: Tim Bray Subject: Re: atom:id again... Please accept my apologies for doing this now... Cc: Paul Hoffman / IMC , Atom WG in-reply-to: <1F910F3F-155D-11D9-A6CA-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> <1F910F3F-155D-11D9-A6CA-000A95A51C9E@sun.com> X-Originating-IP: 161.73.18.78/instID=43 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, October 03, 2004, at 10:04AM, Tim Bray wrote: >OK. Who's writing a Pace to clean up the language? I did, weeks ago: http://www.intertwingly.net/wiki/pie/PaceIdConstruct2 Graham From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19:04 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 TAA26281 for ; Sun, 3 Oct 2004 19:19: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 i93GtxeX039050; Sun, 3 Oct 2004 09:55:59 -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 i93Gtxpq039049; Sun, 3 Oct 2004 09:55:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93GtweS039036; Sun, 3 Oct 2004 09:55:58 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i93Gu153016746; Sun, 3 Oct 2004 10:56:01 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5000DXJPPCM0@edgemail1.Central.Sun.COM>; Sun, 03 Oct 2004 10:56:01 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I50004Q2PPCS0@mail.sun.net>; Sun, 03 Oct 2004 10:56:00 -0600 (MDT) Date: Sun, 03 Oct 2004 09:56:08 -0700 From: Tim Bray Subject: Re: atom:id again... Please accept my apologies for doing this now... In-reply-to: To: Paul Hoffman / IMC Cc: Atom WG Message-id: <1F910F3F-155D-11D9-A6CA-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 3, 2004, at 9:26 AM, Paul Hoffman / IMC wrote: >> Currently I can point to "universally unique" and claim it bans >> serving a feed twice with the same ids. > > +0.5 > >> Equally I can claim it says a feed must use the same 15 ids for its >> entries regardless of which 15 entries it currently contains. It is >> one of the most hand-wavey bits of the spec, so claiming it means >> anything specific is a bit off. > > +1 > >> (Also " that is universally unique; i.e., it MUST NOT change over >> time" is a complete non sequitur.) > > +1. Good point. "universally" does not necessarily mean "over time". OK. Who's writing a Pace to clean up the language? -Tim From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19: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 TAA26298 for ; Sun, 3 Oct 2004 19:19: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 i93GcA8b038140; Sun, 3 Oct 2004 09:38:10 -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 i93GcAJJ038139; Sun, 3 Oct 2004 09:38:10 -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 i93Gc9P3038133 for ; Sun, 3 Oct 2004 09:38:09 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.100]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CE9N9-0004GU-Tt; Sun, 03 Oct 2004 16:38:08 +0000 Message-ID: <41602AF2.4050808@franklinmint.fm> Date: Sun, 03 Oct 2004 12:38:10 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: Tim Bray , bobwyman@pubsub.com, atom-syntax@imc.org Subject: Re: atom:id again... Please accept my apologies for doing this now... References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> In-Reply-To: <1257445.1096819580433.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > On Sunday, October 03, 2004, at 08:45AM, Tim Bray wrote: > > >>"Universally unique" means that any two atom:entries that have the same >>atom:id are the same atom:entry. > > > Does it? Where does it say that? > > >>I don't think there's anything in any >>of our current draft language that I could point to and say "it's >>illegal because of *this*". > > > Currently I can point to "universally unique" and claim it bans serving a feed twice with the same ids. Equally I can claim it says a feed must use the same 15 ids for its entries regardless of which 15 entries it currently contains. It is one of the most hand-wavey bits of the spec, so claiming it means anything specific is a bit off. > > (Also " that is universally unique; i.e., it MUST NOT change over time" is a complete non sequitur.) The spec is trying to say that atom:id is a reference. You can change what the reference is bound to, but don't use a different reference for the same resource. If I write an entry about losing my cat, http://example.org/i_lost_my_cat that URI should never change, but the result of dereferencing it may. I understand Bob's dilemma, but I'm not sure he's hit on the right formula. The fact that he wants to include more than one instance indicates that each update should have its own URI. "My assumption is that for most people, the only interesting information is going to be the current status. However, there are a number of applications that would require the ability to track changes in status over time. For those who only care about current status, we only need to have one entry for any airport in our feed-- the most recent one. For those who care about changes over time, we should provide access to all entries for some given time period (even entries that are now "old" and obsolete) so that they can be sure to pick up everything they need without gaps." The way to provide access to changes in status over time is to give each one of them a URI, and relate them. Perhaps or a category could be used to indicate the relationship between the Airport status entries. Or, perhaps the feed should only include one entry per airport at any given time. The app can start tracking changes from the current point in time, rather than ten entries ago. In any case, this is not an approach we should endorse in any way. We should specifically call it out as undefined or ban it. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19: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 TAA26327 for ; Sun, 3 Oct 2004 19:19:05 -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 i93FoWUJ032686; Sun, 3 Oct 2004 08:50: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 i93FoWm0032685; Sun, 3 Oct 2004 08:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i93FoVaJ032675 for ; Sun, 3 Oct 2004 08:50:31 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041003154959.80743.qmail@web41207.mail.yahoo.com> Received: from [67.160.85.184] by web41207.mail.yahoo.com via HTTP; Sun, 03 Oct 2004 08:49:59 PDT Date: Sun, 3 Oct 2004 08:49:59 -0700 (PDT) From: Dare Obasanjo Subject: RE: PaceReformedContent3 To: bob@wyman.us, "'Tim Bray'" , "'Atom-Syntax Syntax'" In-Reply-To: <200410030625.BTP81718@ms8.netsolmail.com> 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: --- Bob Wyman wrote: > > What exactly do you expect aggregators like > Bloglines, RSS Bandit > > or Newsgator to do with some random XML content? > At least with our "Atom over XMPP PubSub" service, > we will be > providing sets of XSL Templates as part of the > metadata for the feed. Thus, > aggregators that find data with unknown xml types in > them will also be > provided with the XML Templates needed to convert > those types to > representations more useful to them. (i.e. > conversion to XHTML, etc.) So do you really think I'm going to implement support for executing arbitrary code due to directives in an RSS/Atom feed? Thanks but no thanks. I paid attention during Security month at Microsoft 2.5 years ago. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19:07 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 TAA26332 for ; Sun, 3 Oct 2004 19:19: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 i93GQEjY037493; Sun, 3 Oct 2004 09:26:14 -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 i93GQEov037492; Sun, 3 Oct 2004 09:26:14 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93GQCP9037486 for ; Sun, 3 Oct 2004 09:26:13 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1257445.1096819580433.JavaMail.dtcd@mac.com> References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> Date: Sun, 3 Oct 2004 09:26:17 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: atom:id again... Please accept my apologies for doing this now... 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 9:06 AM -0700 10/3/04, Graham Parks wrote: >Currently I can point to "universally unique" and claim it bans >serving a feed twice with the same ids. +0.5 > Equally I can claim it says a feed must use the same 15 ids for its >entries regardless of which 15 entries it currently contains. It is >one of the most hand-wavey bits of the spec, so claiming it means >anything specific is a bit off. +1 >(Also " that is universally unique; i.e., it MUST NOT change over >time" is a complete non sequitur.) +1. Good point. "universally" does not necessarily mean "over time". > > is now compulsory. Hmm... do we want to require that no >>feed contain two entries with the same and ? >>I'm inclined not to worry, this would be stupid but tend not to break >>software, if I were writing the software I'd be inclined to do >>something like > >Unless there are specific processing rules for finding the most >recent entry, it should be banned. Why? What is the interoperability issue here? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19:07 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 TAA26352 for ; Sun, 3 Oct 2004 19:19: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 i93G6IIi036079; Sun, 3 Oct 2004 09:06: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 i93G6IJ8036078; Sun, 3 Oct 2004 09:06:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93G6Ibs036071 for ; Sun, 3 Oct 2004 09:06:18 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail09-en1 [10.13.10.98]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i93G6LLU016402; Sun, 3 Oct 2004 09:06:21 -0700 (PDT) Received: from webmail09 (localhost [127.0.0.1]) by mac.com (Xserve/webmail09/MantshX 4.0) with ESMTP id i93G6K5P014727; Sun, 3 Oct 2004 09:06:20 -0700 (PDT) Message-ID: <1257445.1096819580433.JavaMail.dtcd@mac.com> Date: Sun, 03 Oct 2004 09:06:20 -0700 From: Graham Parks To: Tim Bray Subject: Re: atom:id again... Please accept my apologies for doing this now... Cc: bobwyman@pubsub.com, atom-syntax@imc.org in-reply-to: <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> X-Originating-IP: 161.73.18.78/instID=42 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, October 03, 2004, at 08:45AM, Tim Bray wrote: >"Universally unique" means that any two atom:entries that have the same >atom:id are the same atom:entry. Does it? Where does it say that? >I don't think there's anything in any >of our current draft language that I could point to and say "it's >illegal because of *this*". Currently I can point to "universally unique" and claim it bans serving a feed twice with the same ids. Equally I can claim it says a feed must use the same 15 ids for its entries regardless of which 15 entries it currently contains. It is one of the most hand-wavey bits of the spec, so claiming it means anything specific is a bit off. (Also " that is universally unique; i.e., it MUST NOT change over time" is a complete non sequitur.) > is now compulsory. Hmm... do we want to require that no >feed contain two entries with the same and ? >I'm inclined not to worry, this would be stupid but tend not to break >software, if I were writing the software I'd be inclined to do >something like Unless there are specific processing rules for finding the most recent entry, it should be banned. Graham From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19: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 TAA26372 for ; Sun, 3 Oct 2004 19:19: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 i93FjSwG032354; Sun, 3 Oct 2004 08:45: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 i93FjSRc032353; Sun, 3 Oct 2004 08:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93FjR2L032347 for ; Sun, 3 Oct 2004 08:45:27 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i93FjTil015770 for ; Sun, 3 Oct 2004 09:45:30 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I500079MMFTXS@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Oct 2004 09:45:30 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I50004ORMFSRL@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Oct 2004 09:45:29 -0600 (MDT) Date: Sun, 03 Oct 2004 08:45:36 -0700 From: Tim Bray Subject: Re: atom:id again... Please accept my apologies for doing this now... In-reply-to: <11098762.1096816814331.JavaMail.dtcd@mac.com> To: Graham Parks Cc: bobwyman@pubsub.com, atom-syntax@imc.org Message-id: <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 3, 2004, at 8:20 AM, Graham Parks wrote: >> It's not obvious which rule you're breaking. > > What interpretation of "universally unique" are you using that's > narrow enough to not include other entries in the same XML doc? "Universally unique" means that any two atom:entries that have the same atom:id are the same atom:entry. I don't think there's anything in any of our current draft language that I could point to and say "it's illegal because of *this*". If people want to make it illegal it would require some extra work, and I'm not sure it's worth doing. >> Given that there will be >> multiple different versions of an entry, it seems that receiving >> software can do one of two things: forget all but the most recent, or >> store successive versions. > > And which is the most recent Tim? is now compulsory. Hmm... do we want to require that no feed contain two entries with the same and ? I'm inclined not to worry, this would be stupid but tend not to break software, if I were writing the software I'd be inclined to do something like WHEN I find an entry IF I have its atom:id on file IF its atom:date is later than the atom:date on file replace the current one flag update for user ELSE ignore it -Tim From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19:09 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 TAA26391 for ; Sun, 3 Oct 2004 19:19:08 -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 i93G9oFq036575; Sun, 3 Oct 2004 09:09: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 i93G9oFW036574; Sun, 3 Oct 2004 09:09:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i93G9omr036564 for ; Sun, 3 Oct 2004 09:09:50 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041003160948.80896.qmail@web41202.mail.yahoo.com> Received: from [67.160.85.184] by web41202.mail.yahoo.com via HTTP; Sun, 03 Oct 2004 09:09:48 PDT Date: Sun, 3 Oct 2004 09:09:48 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: "Asbjørn" Ulsberg , Tim Bray Cc: Atom-Syntax In-Reply-To: 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: --- Asbjørn Ulsberg wrote: > > > Specifically a number of text/plain documents on > the Web [such as > > IETF RFCs] contain form feed characters which are > illegal in XML. > > They of course need to be escaped, but that's the > natural process of > putting _anything_ into an XML document. Wrong. They are ILLEGAL characters in XML. There is no escaping them in a non-application specific way. So far the consensus I've seen when this was brought up was to base64 encode text/plain content. > > (b) Using MIME type parameters is a lot of > UNNECESSARY complexity > > to push on clients. > > But still, 'format=flowed' is very useful. How is > whitespace supposed to > be handled when @type is equal to TEXT? When using > 'text/plain' with and > without 'format=flowed', this is very explicit. > Without this parameter, > the whitespace is preserved and static, with it > present, the text flows. The spec can have rules for how the value of the atom:content element should be processed when type='text'. This seems a lot simpler and more straightforward than requiring clients to support MIME type parameters. > > > > (a) Less ambiguity. > > What is ambigous with 'text/plain', exactly? The fact that you just got confused about the fact that text/plain has characters that are illegal in XML versus 'needing to be escaped' speaks volumes to me. It implies you and many others like you would expect that you could just emit text/plain documents in XML files without base64 encoding it or stripping illegal characters thus causing failures in consumers that use conformant XML parsers. A large number of text/plain documents are not legal content for an XML file. > > > (b) Less complexity for content producers and feed > consumers. > > No, they need to check and parse the value of @type > no matter what we do. > I don't understand how it's more difficult to check > for the occurence of > 'text/plain' or 'text/html' in comparison to 'TEXT' > or 'HTML'. That comment was specific to supporting MIME type parameters which is a lot more complex than switching on 'text' or 'html'. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Sun Oct 3 19:19: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 TAA26412 for ; Sun, 3 Oct 2004 19:19: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 i93FKCH7031225; Sun, 3 Oct 2004 08:20: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 i93FKCSI031224; Sun, 3 Oct 2004 08:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93FKCCp031217 for ; Sun, 3 Oct 2004 08:20:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail27-en1 [10.13.10.127]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i93FKESr004160; Sun, 3 Oct 2004 08:20:14 -0700 (PDT) Received: from webmail27 (localhost.mac.com [127.0.0.1]) by mac.com (Xserve/webmail27/MantshX 4.0) with ESMTP id i93FKEpG018347; Sun, 3 Oct 2004 08:20:14 -0700 (PDT) Message-ID: <11098762.1096816814331.JavaMail.dtcd@mac.com> Date: Sun, 03 Oct 2004 08:20:14 -0700 From: Graham Parks To: Tim Bray Subject: Re: atom:id again... Please accept my apologies for doing this now... Cc: bobwyman@pubsub.com, atom-syntax@imc.org in-reply-to: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <20041003004057.7F35EA4E063@mail.pubsub.com> X-Originating-IP: 161.73.18.78/instID=131 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, October 03, 2004, at 00:20AM, Tim Bray wrote: >It's not obvious which rule you're breaking. What interpretation of "universally unique" are you using that's narrow enough to not include other entries in the same XML doc? >Given that there will be >multiple different versions of an entry, it seems that receiving >software can do one of two things: forget all but the most recent, or >store successive versions. And which is the most recent Tim? I think the only answer here is that each update should have its own id and each aiprort its own feed. That maps it to how blogs work, and we are creating a blogging protocol. Graham From owner-atom-syntax@mail.imc.org Sun Oct 3 19:21: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 TAA26482 for ; Sun, 3 Oct 2004 19:21: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 i93EU3rq028480; Sun, 3 Oct 2004 07:30:03 -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 i93EU3bc028479; Sun, 3 Oct 2004 07:30:03 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93ETwcJ028465; Sun, 3 Oct 2004 07:29:58 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20041003004057.7F35EA4E063@mail.pubsub.com> References: <20041003004057.7F35EA4E063@mail.pubsub.com> Date: Sun, 3 Oct 2004 07:30:01 -0700 To: , From: Paul Hoffman / IMC Subject: Re: atom:id again... Please accept my apologies for doing this now... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I don't see any obvious protocol problem, but I hope you don't expect any particular action on the part of the receiver. This kind of over-loading is common in protocols; the problem is a few years down the line when a new implementer starts up and sees streams like this in the wild, they want to know what they are "supposed" to do with them. As long as the answer is "it's undefined", no one is the worse for it. You might consider also creating an extension that will give the history-keeping readers some context, such as the order from the publisher's perspective. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Oct 3 19:24:13 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 TAA26558 for ; Sun, 3 Oct 2004 19:24:12 -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 i93BeGZk016805; Sun, 3 Oct 2004 04:40: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 i93BeGOT016804; Sun, 3 Oct 2004 04:40:16 -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 i93BeFxI016793 for ; Sun, 3 Oct 2004 04:40:16 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id B6DB07C22E; Sun, 3 Oct 2004 14:29:22 +0200 (CEST) Date: Sun, 03 Oct 2004 13:43:18 +0200 To: "Antone Roundy" Subject: Re: PaceReformedContent3 Cc: Atom-Syntax References: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 2 Oct 2004 18:04:30 -0600, Antone Roundy wrote: > Is there a difference between the XML mode and the plain text mode? This has been discussed before, and as far as I can remember; yes, there is. Typically, I don't remember what at the moment. > In either, anything that looks like markup but isn't (eg. you want the > user to see , not to get blinking text) has to be escaped. True. > Plain text can't contain actual markup, but that's a matter of the > content > type, not the mode. Also true. Maybe 'text/*' (excluding 'text/html') should go into the «XML» mode, then? Hm. > P.S. Is there any way to search the mailing list archive? I'm currently writing a Windows application for doing just that. It's far from finished, but I can keep the list posted of its progress, if it's interesting. > I find myself vaguely remembering things having been discussed before, > but > not knowing a quick way to find them. Same here. It wouldn't hurt having the archive marked up better either, so it was easier to crawl and parse with a robot. Also, having the Message-ID in the archive would be nice. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Oct 3 19:24:13 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 TAA26566 for ; Sun, 3 Oct 2004 19:24:13 -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 i93BYqAf016495; Sun, 3 Oct 2004 04:34: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 i93BYqFx016494; Sun, 3 Oct 2004 04:34: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 (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93BYpJD016480 for ; Sun, 3 Oct 2004 04:34:52 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 34E8C7C1EE; Sun, 3 Oct 2004 14:23:51 +0200 (CEST) Date: Sun, 03 Oct 2004 13:37:46 +0200 To: "Dare Obasanjo" , "Tim Bray" Subject: Re: PaceReformedContent3 Cc: Atom-Syntax References: <20041003003756.6917.qmail@web41213.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20041003003756.6917.qmail@web41213.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 2 Oct 2004 17:37:56 -0700 (PDT), Dare Obasanjo wrote: >> What I don't understand is the 'TEXT' type. How does this differ from >> 'text/plain'? At least, with 'text/plain', you can add MIME type >> parameters, while I guess this is disallowed for 'TEXT'. Am I correct? > > (a) Content that is text/plain may contain characters that are not > valid XML characters. No. Well, served directly over HTTP, that is the case. But wrapped in XML, the same rule applies to all content. It even applies to 'text/*' types in the pace as it stands now, as far as I can understand. > Specifically a number of text/plain documents on the Web [such as > IETF RFCs] contain form feed characters which are illegal in XML. They of course need to be escaped, but that's the natural process of putting _anything_ into an XML document. The character '<' is accidently represented as '<' in XML. That's the way it is, and it has nothing to do with the MIME type wrapped up in the XML document. Using a conforming tool, you should never have to see the four characters '<' anyway. > (b) Using MIME type parameters is a lot of UNNECESSARY complexity > to push on clients. But still, 'format=flowed' is very useful. How is whitespace supposed to be handled when @type is equal to TEXT? When using 'text/plain' with and without 'format=flowed', this is very explicit. Without this parameter, the whitespace is preserved and static, with it present, the text flows. >> What do we gain by using the four uppercase letters 'TEXT' from >> using the MIME type 'text/plain' (optionally with parameters)? > > (a) Less ambiguity. What is ambigous with 'text/plain', exactly? That you can't squeeze all characters into the XML document? Well, as mentioned above, this applies to all values of @type, no matter what. No content type can change the rules of XML. > (b) Less complexity for content producers and feed consumers. No, they need to check and parse the value of @type no matter what we do. I don't understand how it's more difficult to check for the occurence of 'text/plain' or 'text/html' in comparison to 'TEXT' or 'HTML'. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Oct 3 19: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 TAA26593 for ; Sun, 3 Oct 2004 19: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 i939o1JH088236; Sun, 3 Oct 2004 02:50:01 -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 i939o1cG088234; Sun, 3 Oct 2004 02:50:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i939o19d088224 for ; Sun, 3 Oct 2004 02:50:01 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8544D4F237; Sun, 3 Oct 2004 05:50:00 -0400 (EDT) Message-Id: <4.2.0.58.J.20041003184206.036c5e40@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 03 Oct 2004 18:44:07 +0900 To: Dare Obasanjo , =?ISO-2022-JP?B?IkFzYmobJEJ4chsoQm4i?= Ulsberg , Tim Bray From: Martin Duerst Subject: Re: PaceReformedContent3 Cc: Atom-Syntax In-Reply-To: <20041003003756.6917.qmail@web41213.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 At 17:37 04/10/02 -0700, Dare Obasanjo wrote: >--- Asbj$Bxr(Bn Ulsberg wrote: > > > > What I don't understand is the 'TEXT' type. How does > > this differ from > > 'text/plain'? At least, with 'text/plain', you can > > add MIME type > > parameters, while I guess this is disallowed for > > 'TEXT'. Am I correct? > >(a) Content that is text/plain may contain characters >that are not valid XML characters. Specifically a >number of text/plain documents on the Web [such as >IETF RFCs] contain form feed characters which are >illegal in XML. Well, but the current proposal doesn't allow these characters in places declared as type='text/plain', because text/plain does not use base64. From owner-atom-syntax@mail.imc.org Sun Oct 3 19:24:16 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 TAA26610 for ; Sun, 3 Oct 2004 19:24:15 -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 i939nuE6088196; Sun, 3 Oct 2004 02:49: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 i939nuAa088195; Sun, 3 Oct 2004 02:49:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i939nt1X088184 for ; Sun, 3 Oct 2004 02:49:56 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 4E39E4F237; Sun, 3 Oct 2004 05:49:55 -0400 (EDT) Message-Id: <4.2.0.58.J.20041003183206.03684360@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 03 Oct 2004 18:34:05 +0900 To: Tim Bray From: Martin Duerst Subject: Re: PaceReformedContent3 Cc: Atom-Syntax Syntax In-Reply-To: References: <4.2.0.58.J.20040930083637.06962f00@localhost> <4.2.0.58.J.20040929130431.066f0de0@localhost> <4.2.0.58.J.20040929084918.065308b0@localhost> <4.2.0.58.J.20040928164143.05654b30@localhost> <4.2.0.58.J.20040928164143.05654b30@localhost> <4.2.0.58.J.20040929084918.065308b0@localhost> <4.2.0.58.J.20040929130431.066f0de0@localhost> <4.2.0.58.J.20040930083637.06962f00@localhost> Mime-Version: 1.0 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 19:46 04/09/29 -0700, Tim Bray wrote: >On Sep 29, 2004, at 4:39 PM, Martin Duerst wrote: > >>So you are saying that type='TEXT/plain' or type="IMAGE/SVG+XML' are >>legal, but type='html' or type='xhtml' aren't? > >Exactly. You check for a literal match against "TEXT", "HTML", or "XHTML" >and if all three fail then you hand it to a media-type handler, which >presumably knows about the rules for media types. Why is it better if I >have to do case-folding before checking? -Tim Given that I found the word 'case' exactly once in the Pace, and not in the context of upper/lower case, I think it would be extremely prudent to at least make these expectations VERY explicit in the text. But I still think they will be confusing to quite a few people. Regards, Martin. From owner-atom-syntax@mail.imc.org Sun Oct 3 19:29:23 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 TAA27108 for ; Sun, 3 Oct 2004 19:29:23 -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 i936mh3j028957; Sat, 2 Oct 2004 23:48:43 -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 i936mhtr028956; Sat, 2 Oct 2004 23:48:43 -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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i936mgA6028944 for ; Sat, 2 Oct 2004 23:48:42 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so2699847rnl for ; Sat, 02 Oct 2004 23:48:42 -0700 (PDT) Received: by 10.38.171.77 with SMTP id t77mr4862060rne; Sat, 02 Oct 2004 23:48:42 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Sat, 2 Oct 2004 23:48:42 -0700 (PDT) Message-ID: <540e37320410022348307b14ed@mail.gmail.com> Date: Sun, 3 Oct 2004 01:48:42 -0500 From: "Roger B." Reply-To: "Roger B." To: Eric Scheid Subject: Re: PaceReformedContent3 Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041003052637.73483.qmail@web41209.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > ... > blah blah blah > > Eric: +1. In my case, if I don't see text/html or application/xhtml+xml, I currently grab the content element's text node and run with it... in an embedded XML scenario, that means I may end up displaying a (mostly) empty entry, but nothing will catch fire. If the publisher can live with that, so can I. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Sun Oct 3 19:29:26 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 TAA27159 for ; Sun, 3 Oct 2004 19:29:26 -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 i935q8s0005293; Sat, 2 Oct 2004 22:52: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 i935q8kk005292; Sat, 2 Oct 2004 22:52:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i935q64K004920 for ; Sat, 2 Oct 2004 22:52:07 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 3 Oct 2004 15:51:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 03 Oct 2004 15:51:40 +1000 Subject: Re: PaceReformedContent3 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041003052637.73483.qmail@web41209.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/10/04 3:26 PM, "Dare Obasanjo" wrote: > http://earthquake.usgs.gov/recenteqsww/eqs1day-M2.5.xml >> it would be real nice if they could just insert one >> of the XML objects they >> normally produce directly in an Atom file. > > Why would this be "nice"? What exactly do you expect > aggregators like Bloglines, RSS Bandit or Newsgator to > do with some random XML content? At least with > namespaced extension elements they can be ignored by > aggregators unaware of how to process elements from > that namespace and human readable alternatives can be > provided in atom:content. > where would you put the name spaced elements? would the following work... ... blah blah blah thus you have one content element which most general-reader aggregators can handle, and you have xml content which a specialist aggregator can pick up on. e. From owner-atom-syntax@mail.imc.org Sun Oct 3 19:29:27 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 TAA27172 for ; Sun, 3 Oct 2004 19:29:26 -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 i936XQMG023418; Sat, 2 Oct 2004 23:33:26 -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 i936XQvZ023417; Sat, 2 Oct 2004 23:33:26 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i936XO6g023393 for ; Sat, 2 Oct 2004 23:33:25 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so1322644rnl for ; Sat, 02 Oct 2004 23:33:22 -0700 (PDT) Received: by 10.38.126.4 with SMTP id y4mr1452827rnc; Sat, 02 Oct 2004 23:33:22 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Sat, 2 Oct 2004 23:33:22 -0700 (PDT) Message-ID: <540e3732041002233331318eac@mail.gmail.com> Date: Sun, 3 Oct 2004 01:33:22 -0500 From: "Roger B." Reply-To: "Roger B." To: bobwyman@pubsub.com Subject: Re: atom:id again... Please accept my apologies for doing this now... Cc: atom-syntax@imc.org In-Reply-To: <20041003004057.7F35EA4E063@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041003004057.7F35EA4E063@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob: I have a feeling that, unless an aggregator displays diffs within its interface, history-seeking users aren't going to get what they want from the feed. Many will simply get one of the following: (a) The most recent (by date) entry overwriting its predecessor. (b) The last (by element order) entry in the feed overwriting its predecessors. (c) All additional entries after the original being ignored as duplicates. Of course, if the total audience for a "history feed" is small enough, and is willing to use a specific tool to get specific results, it might be a pretty good idea. That aside, does it "break the rules"? Not in my opinion, at least not at first glance. Variant results aren't necessarily a sign of breakage. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Sun Oct 3 19:29:27 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 TAA27189 for ; Sun, 3 Oct 2004 19:29:27 -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 i935QZsh092630; Sat, 2 Oct 2004 22:26:35 -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 i935QZtk092629; Sat, 2 Oct 2004 22:26:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i935QZJa092591 for ; Sat, 2 Oct 2004 22:26:35 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041003052637.73483.qmail@web41209.mail.yahoo.com> Received: from [67.160.85.184] by web41209.mail.yahoo.com via HTTP; Sat, 02 Oct 2004 22:26:37 PDT Date: Sat, 2 Oct 2004 22:26:37 -0700 (PDT) From: Dare Obasanjo Subject: RE: PaceReformedContent3 To: bob@wyman.us, "'Tim Bray'" , "'Atom-Syntax Syntax'" In-Reply-To: <200410030132.BTP55571@ms8.netsolmail.com> 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: --- Bob Wyman wrote: > > I guess I must be a geek... I'm definitely "on this > list"... But, > I'm also a publisher... > Please see: > http://www.imc.org/atom-syntax/mail-archive/msg10250.html > In which I provide an example of XML that we are > embedding in atom:content > today. This works with Atom 0.3. How should I > migrate this to Atom 1.0? > > Also, could you tell me how USGS should best > migrate their existing > Earthquake RSS feeds to Atom? Currently, they just > use a few namespaced > extension tags. But, instead of what they do today: > See: > http://earthquake.usgs.gov/recenteqsww/eqs1day-M2.5.xml > it would be real nice if they could just insert one > of the XML objects they > normally produce directly in an Atom file. Why would this be "nice"? What exactly do you expect aggregators like Bloglines, RSS Bandit or Newsgator to do with some random XML content? At least with namespaced extension elements they can be ignored by aggregators unaware of how to process elements from that namespace and human readable alternatives can be provided in atom:content. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Sun Oct 3 19:29:28 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 TAA27208 for ; Sun, 3 Oct 2004 19:29:28 -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 i936ZlWv024294; Sat, 2 Oct 2004 23:35:47 -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 i936Zldd024293; Sat, 2 Oct 2004 23:35:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i936ZHWT024079 for ; Sat, 2 Oct 2004 23:35:17 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i936Yarb003727; Sun, 3 Oct 2004 02:35:16 -0400 (EDT) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTP82731 (AUTH bob@wyman.us); Sun, 3 Oct 2004 02:34:35 -0400 (EDT) Message-Id: <200410030634.BTP82731@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: PaceReformedContent3 Date: Sun, 3 Oct 2004 02:34:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSpDyomx769l9JLRL+9x+Rgk2hrNQAArLSQ In-reply-to: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >would the following work... > > ... > blah blah blah > > > thus you have one content element which most general-reader > aggregators can handle, and you have xml content which a > specialist aggregator can pick up on. I would argue against this solution for two reasons: 1. Requiring that data be duplicated for the benefit of non-"specialist" applications could be a serious burden. In many cases, the size of entries can be substantial. Also, it is likely that in many cases, the specialist data would only be of interest to specialist applications. Thus, it would be a pity to require conversion to accommodate non-existent non-specialist readers. Not all aggregators will be interested in reading all files... 2. This increases the complexity of the by providing for alternative content elements. I'm not sure *this* is *the* good reason to introduce this concept. There are all sorts of ways that alternative content elements could be used and abused and the idea should have much more justification before it is pursued. What we plan to do is provide access to XSL Templates that will instruct readers how to convert the XML data to default representations like XHTML. This will be done via node level metadata in our "Atom over XMPP PubSub" implementations. My hope is that we'll be able to do the same in Atom files. bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 3 19:29:29 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 TAA27224 for ; Sun, 3 Oct 2004 19:29:28 -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 i936PBS3020321; Sat, 2 Oct 2004 23:25:11 -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 i936PBtd020320; Sat, 2 Oct 2004 23:25:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i936PAms020294 for ; Sat, 2 Oct 2004 23:25:10 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i936P7rb002366; Sun, 3 Oct 2004 02:25:07 -0400 (EDT) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTP81718 (AUTH bob@wyman.us); Sun, 3 Oct 2004 02:25:06 -0400 (EDT) Message-Id: <200410030625.BTP81718@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , , "'Tim Bray'" , "'Atom-Syntax Syntax'" Subject: RE: PaceReformedContent3 Date: Sun, 3 Oct 2004 02:24:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSpCZQ8vJsLJ+kIQWGz5yDZBzEo1wABmyLw In-reply-to: <20041003052637.73483.qmail@web41209.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > At least with namespaced extension elements they can be ignored > by aggregators unaware of how to process elements from that > namespace and human readable alternatives can be provided > in atom:content. Please accept my apologies for having provided incomplete examples. Clearly, the namespaces need to be identified. > What exactly do you expect aggregators like Bloglines, RSS Bandit > or Newsgator to do with some random XML content? At least with our "Atom over XMPP PubSub" service, we will be providing sets of XSL Templates as part of the metadata for the feed. Thus, aggregators that find data with unknown xml types in them will also be provided with the XML Templates needed to convert those types to representations more useful to them. (i.e. conversion to XHTML, etc.) My hope is that we'll be able to define some element or elements in Atom files that would allow us to link to the same templates. If there isn't a standard mechanism for doing this, we would have to define something in our own namespace. > Why would this be "nice"? It is nice since it allows people to syndicate data that is generated by non-blogging applications without having to do excessive and potentially fragile conversions of data. This allows the existing applications to leverage the syndication infrastructure most efficiently. The alternatives, like hacking all sorts of extensions into XHTML, don't seem to offer much of value. bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 3 19:31:04 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 TAA27271 for ; Sun, 3 Oct 2004 19:31: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 i93NLIk0064902; Sun, 3 Oct 2004 16:21: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 i93NLI9J064901; Sun, 3 Oct 2004 16:21:18 -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 i93NLHnC064888; Sun, 3 Oct 2004 16:21:17 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.3]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CEFfK-0002Xg-46; Sun, 03 Oct 2004 23:21:18 +0000 Message-ID: <41608971.8080900@franklinmint.fm> Date: Sun, 03 Oct 2004 19:21:21 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: Tim Bray , Paul Hoffman / IMC , Atom WG Subject: Re: atom:id again... Please accept my apologies for doing this now... References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> <1F910F3F-155D-11D9-A6CA-000A95A51C9E@sun.com> <8284336.1096823710795.JavaMail.dtcd@mac.com> In-Reply-To: <8284336.1096823710795.JavaMail.dtcd@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > On Sunday, October 03, 2004, at 10:04AM, Tim Bray wrote: > > >>OK. Who's writing a Pace to clean up the language? > > > I did, weeks ago: > http://www.intertwingly.net/wiki/pie/PaceIdConstruct2 How about this: 3.5 Identification Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content MUST be an absolute URI [RFC2396]. When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content its Identity construct MUST NOT change. Put another way, an Identity construct pertains to all instantiations of a particular Atom document; revisions to the Atom document retain the same content in their Identity constructs. Compare and contrast to RFC822: 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Oct 3 19:33:04 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 TAA27361 for ; Sun, 3 Oct 2004 19:33: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 i93NS95V065309; Sun, 3 Oct 2004 16:28:09 -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 i93NS9n6065308; Sun, 3 Oct 2004 16:28:09 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93NS5cZ065302; Sun, 3 Oct 2004 16:28:05 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <41608971.8080900@franklinmint.fm> References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> <1F910F3F-155D-11D9-A6CA-000A95A51C9E@sun.com> <8284336.1096823710795.JavaMail.dtcd@mac.com> <41608971.8080900@franklinmint.fm> Date: Sun, 3 Oct 2004 16:28:09 -0700 To: Robert Sayre , Graham Parks From: Paul Hoffman / IMC Subject: Re: atom:id again... Please accept my apologies for doing this now... Cc: Tim Bray , Atom WG 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 7:21 PM -0400 10/3/04, Robert Sayre wrote: >How about this: > When an Atom document is relocated, migrated, syndicated, > republished, exported or imported, the content its Identity > construct MUST NOT change. Wording glitch there.... --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Oct 3 19:34:33 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 TAA27416 for ; Sun, 3 Oct 2004 19:34:32 -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 i93NPoxL065178; Sun, 3 Oct 2004 16:25: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 i93NPoGx065177; Sun, 3 Oct 2004 16:25:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93NPnmN065165 for ; Sun, 3 Oct 2004 16:25:49 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i93NPqrb014538 for ; Sun, 3 Oct 2004 19:25:52 -0400 (EDT) Received: from bobdev (dpvc-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTR00354 (AUTH bob@wyman.us); Sun, 3 Oct 2004 19:25:51 -0400 (EDT) Message-Id: <200410032325.BTR00354@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom-Syntax Syntax'" Subject: RFC3229+feed: Empirical Evidence of significant savings. Date: Sun, 3 Oct 2004 19:25:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSpoFcbe4oMkr1gSJiwFGM8mFEtvw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Given that we've been running support for RFC3229+feed on our servers at PubSub.com for a few days now, I thought it might make sense to gather some statistics and see what the savings are. I've documented this analysis on: http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html A summary table of results follows: Status %Requests %TotalBytes AvgBytes 200 15% 85% 77,212 226 10% 14% 18,974 304 73% 53,443 Clearly, use of RFC3229+feed (status code 226) results in very impressive bandwidth savings. Given this, I think we should insist that every aggregator developer support this. I believe that we should keep in mind use of RFC3229+feed when considering how we expect the Atom Syntax to be used in the future. (i.e. The Atom Documents which are returned by servers are likely to frequently represent subsets of the actual Atom Documents stored on a server. The result will be some obfuscation of "editorial" decisions which focus on the significance of whether or not an entry is actually in any particularly instance of an Atom Document.) bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 3 19:43: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 TAA27898 for ; Sun, 3 Oct 2004 19:43: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 i93NaNRL065846; Sun, 3 Oct 2004 16:36: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 i93NaNn4065845; Sun, 3 Oct 2004 16:36:23 -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 i93NaNpl065829; Sun, 3 Oct 2004 16:36:23 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.3]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CEFtw-0003A0-Md; Sun, 03 Oct 2004 23:36:24 +0000 Message-ID: <41608CFB.50401@franklinmint.fm> Date: Sun, 03 Oct 2004 19:36:27 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Graham Parks , Tim Bray , Atom WG Subject: atom:id spec text (was: atom:id again... Please accept my apologies for doing this now...) References: <20041003004057.7F35EA4E063@mail.pubsub.com> <11098762.1096816814331.JavaMail.dtcd@mac.com> <44E6A1E9-1553-11D9-A6CA-000A95A51C9E@sun.com> <1257445.1096819580433.JavaMail.dtcd@mac.com> <1F910F3F-155D-11D9-A6CA-000A95A51C9E@sun.com> <8284336.1096823710795.JavaMail.dtcd@mac.com> <41608971.8080900@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > At 7:21 PM -0400 10/3/04, Robert Sayre wrote: > >> How about this: >> When an Atom document is relocated, migrated, syndicated, >> republished, exported or imported, the content its Identity >> construct MUST NOT change. > > > Wording glitch there.... > How about this: 3.5 Identification Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content MUST be an absolute URI [RFC2396]. When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its Identity construct MUST NOT change. Put another way, an Identity construct pertains to all instantiations of a particular Atom document; revisions to the Atom document retain the same content in their Identity constructs. Compare and contrast to RFC822: 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Oct 3 20:15: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 TAA27115 for ; Sun, 3 Oct 2004 19:29:24 -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 i937JGWE039655; Sun, 3 Oct 2004 00:19: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 i937JGx7039654; Sun, 3 Oct 2004 00:19:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i937JF60039643 for ; Sun, 3 Oct 2004 00:19:15 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i937JF53021540 for ; Sun, 3 Oct 2004 01:19:16 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z00731Z03XS@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Oct 2004 01:19:16 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4Z004GRZ03SH@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Oct 2004 01:19:15 -0600 (MDT) Date: Sun, 03 Oct 2004 00:19:23 -0700 From: Tim Bray Subject: Re: PaceReformedContent3 In-reply-to: <200410030132.BTP55571@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Dare Obasanjo'" , "'Atom-Syntax Syntax'" Message-id: <8CF1050C-150C-11D9-A6CA-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200410030132.BTP55571@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 2, 2004, at 6:32 PM, Bob Wyman wrote: > Please see: > http://www.imc.org/atom-syntax/mail-archive/msg10250.html > In which I provide an example of XML that we are embedding in > atom:content > today. This works with Atom 0.3. How should I migrate this to Atom 1.0? First, you should stop using text/xml, which is bad for a bunch of reasons. Second, if this thing is going to be widely distributed, you should use a real media-type, "text/xml" is broken and "application/xml" is information-free. Third, you should put your own non-atom stuff in a non-atom namespace (I see you acknowledged this in a separate message). Given the above, what's the problem? Most receiving software modules won't have any idea what to do with it, that's OK, and those that recognize it (either by namespace or media-type) will do whatever it is they do. Again, what's the problem? -Tim From owner-atom-syntax@mail.imc.org Sun Oct 3 20:15:36 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 TAA27129 for ; Sun, 3 Oct 2004 19:29:24 -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 i936lL3j028463; Sat, 2 Oct 2004 23:47: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 i936lLlg028462; Sat, 2 Oct 2004 23:47:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i936lL1K028451 for ; Sat, 2 Oct 2004 23:47:21 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i936lK25010741; Sun, 3 Oct 2004 02:47:20 -0400 (EDT) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTP84092 (AUTH bob@wyman.us); Sun, 3 Oct 2004 02:47:19 -0400 (EDT) Message-Id: <200410030647.BTP84092@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Roger B.'" Cc: Subject: RE: atom:id again... Please accept my apologies for doing this now... Date: Sun, 3 Oct 2004 02:47:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSpEuFwOVeEjYVtTqq15+d6Jr5VaAAAG+wQ In-reply-to: <540e3732041002233331318eac@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger Benningfield wrote: > (a) The most recent (by date) entry overwriting its predecessor. > (b) The last (by element order) entry in the feed overwriting its > predecessors. We would probably ensure that these were the same by ensuring the more recent entries were "first" in the feed. However, as a publisher, I think it is reasonable to expect that Atom would define default replacement rules and those rules should be based on the combination of atom:id and date updated. My expectation is that the "history feed" applications would explicitly not implement the default replacement rules and would instead probably just store all instances of entries with the same atom:id. Thus, my expectation is that any statements concerning default replacement rules would be optional. The use of "history" will probably be most important in specialized feeds that carry things like stock-market data, weather, earthquake info, airport status, etc. However, I think we'll find that there will be a number of uses with normal blogging stuff. For instance, we'll have people who will want to implement versioning systems (i.e. CVS or subversion type stuff) and they will want to be able to reconstruct each incremental "state" of an entry. bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 3 20:15:36 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 TAA27145 for ; Sun, 3 Oct 2004 19:29: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 i937DGiB037666; Sun, 3 Oct 2004 00:13: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 i937DGG5037665; Sun, 3 Oct 2004 00:13:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i937DFi6037657 for ; Sun, 3 Oct 2004 00:13:15 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i937DF53020084 for ; Sun, 3 Oct 2004 01:13:15 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z00D86YQ2M0@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Oct 2004 01:13:15 -0600 (MDT) Received: from [192.168.1.24] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I4Z004EBYQ2S0@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Oct 2004 01:13:14 -0600 (MDT) Date: Sun, 03 Oct 2004 00:13:21 -0700 From: Tim Bray Subject: Re: atom:id again... Please accept my apologies for doing this now... In-reply-to: <20041003004057.7F35EA4E063@mail.pubsub.com> To: bobwyman@pubsub.com Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041003004057.7F35EA4E063@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 2, 2004, at 5:40 PM, Bob Wyman wrote: > What I would like to do is create a single tag: URI for each airport. I > would then use that URI as the atom:id for any and every status record > for > that airport. Thus, "tag:pubsub.com,2004:JFK" might be the atom:id we > would > use for *all* JFK reports from now until the universe ends... Doing > this > would make it really easy for applications to handle "replacing" old > entries. They would just make sure that they only had the most recent > instance of any particular atom:id. On the other hand, for the folk > that > want history, I'd like to publish the last 10 alerts or even the last > 24 > hours of alerts to make it easier for them. (I assume that "good" > aggregators would actually use RFC3229+feed and thus wouldn't actually > get > the history unless they needed it.) But, if I publish multiple entries > in a > single atom file and if each entry has the same atom:id, I think I'm > breaking the rules. Is this the case? It's not obvious which rule you're breaking. Given that there will be multiple different versions of an entry, it seems that receiving software can do one of two things: forget all but the most recent, or store successive versions. It doesn't seem to me that whether or not they're in one feed is really that material. -Tim From owner-atom-syntax@mail.imc.org Sun Oct 3 20:41: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 UAA01266 for ; Sun, 3 Oct 2004 20:41: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 i940TKNd069646; Sun, 3 Oct 2004 17:29: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 i940TKpp069645; Sun, 3 Oct 2004 17:29:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i940TJrd069602 for ; Sun, 3 Oct 2004 17:29:19 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 4 Oct 2004 10:28:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Oct 2004 10:19:42 +1000 Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200410032325.BTR00354@ms8.netsolmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/10/04 9:25 AM, "Bob Wyman" wrote: > Given this, I think we should insist that every > aggregator developer support this. -1 you've significantly raised the bar for next to minimal implementations of the most basic utility code. this is not something we should rush into by only considering one side of the issue. e. From owner-atom-syntax@mail.imc.org Sun Oct 3 21:11:49 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 VAA03675 for ; Sun, 3 Oct 2004 21:11:49 -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 i9415rtY071450; Sun, 3 Oct 2004 18:05: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 i9415rsA071449; Sun, 3 Oct 2004 18:05:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9415rkB071436 for ; Sun, 3 Oct 2004 18:05:53 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041004010554.62503.qmail@web41212.mail.yahoo.com> Received: from [24.18.129.209] by web41212.mail.yahoo.com via HTTP; Sun, 03 Oct 2004 18:05:54 PDT Date: Sun, 3 Oct 2004 18:05:54 -0700 (PDT) From: Dare Obasanjo Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. To: bob@wyman.us, "'Atom-Syntax Syntax'" In-Reply-To: <200410032325.BTR00354@ms8.netsolmail.com> 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: --- Bob Wyman wrote: > > Clearly, use of RFC3229+feed (status code 226) > results in very impressive > bandwidth savings. Given this, I think we should > insist that every > aggregator developer support this. Unless the Atom working group became "the aggregator licensing board" this sounds out of scope to me. Also if the Atom working group wants to get in this business there's a bunch of stuff I'd want to see insisted upon first (e.g. gzip support, If-Modified-Since, If-None-Match, etc) before adding support for RFC 3229 to the list. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Oct 3 21:57: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 VAA06190 for ; Sun, 3 Oct 2004 21:57: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 i941o2vR074538; Sun, 3 Oct 2004 18:50: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 i941o2ot074537; Sun, 3 Oct 2004 18:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i941o0b0074505 for ; Sun, 3 Oct 2004 18:50:01 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 14825 invoked by uid 65534); 4 Oct 2004 01:49:54 -0000 Received: from dsl-082-082-076-237.arcor-ip.net (EHLO voyager) (82.82.76.237) by mail.gmx.net (mp011) with SMTP; 04 Oct 2004 03:49:54 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Dare Obasanjo Cc: atom-syntax@imc.org Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. Date: Mon, 04 Oct 2004 03:49:38 +0200 Message-ID: <4183aa17.315963531@smtp.bjoern.hoehrmann.de> References: <200410032325.BTR00354@ms8.netsolmail.com> <20041004010554.62503.qmail@web41212.mail.yahoo.com> In-Reply-To: <20041004010554.62503.qmail@web41212.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >> Clearly, use of RFC3229+feed (status code 226) >> results in very impressive >> bandwidth savings. Given this, I think we should >> insist that every >> aggregator developer support this. > >Unless the Atom working group became "the aggregator >licensing board" this sounds out of scope to me. No, it is common to define conformance criteria for specific classes of products, for example SVG 1.1 defines "SVG Viewers", "SVG Interpreter", "High-Quality Dynamic SVG Viewer", etc. it is perfectly in scope to de- fine conformance requirements for Atom implementations. From owner-atom-syntax@mail.imc.org Sun Oct 3 22:16: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 WAA07314 for ; Sun, 3 Oct 2004 22:16:32 -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 i9428A93075810; Sun, 3 Oct 2004 19:08:10 -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 i9428AZ7075809; Sun, 3 Oct 2004 19:08:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94289o1075801 for ; Sun, 3 Oct 2004 19:08:09 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 4 Oct 2004 12:08:13 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Oct 2004 12:08:13 +1000 Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4183aa17.315963531@smtp.bjoern.hoehrmann.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/10/04 11:49 AM, "Bjoern Hoehrmann" wrote: >> Unless the Atom working group became "the aggregator >> licensing board" this sounds out of scope to me. > > No, it is common to define conformance criteria for specific classes of > products, for example SVG 1.1 defines "SVG Viewers", "SVG Interpreter", > "High-Quality Dynamic SVG Viewer", etc. it is perfectly in scope to de- > fine conformance requirements for Atom implementations. it may be in scope for the generic class of organisations which atom-pub WG is, but is it in our specific charter? e. From owner-atom-syntax@mail.imc.org Sun Oct 3 22:26:50 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 WAA07778 for ; Sun, 3 Oct 2004 22:26:50 -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 i942Ia6i076289; Sun, 3 Oct 2004 19:18:36 -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 i942IaFo076288; Sun, 3 Oct 2004 19:18:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i942IZ57076275 for ; Sun, 3 Oct 2004 19:18:35 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 32764 invoked by uid 65534); 4 Oct 2004 02:18:35 -0000 Received: from dsl-082-082-076-237.arcor-ip.net (EHLO voyager) (82.82.76.237) by mail.gmx.net (mp013) with SMTP; 04 Oct 2004 04:18:35 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Eric Scheid Cc: Atom Syntax Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. Date: Mon, 04 Oct 2004 04:18:17 +0200 Message-ID: <4184adc9.316909281@smtp.bjoern.hoehrmann.de> References: <200410032325.BTR00354@ms8.netsolmail.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Eric Scheid wrote: >> Given this, I think we should insist that every >> aggregator developer support this. > >-1 > >you've significantly raised the bar for next to minimal implementations of >the most basic utility code. What do you mean by "significantly" here? Do you have any material on the implementation cost of RFC 3229? How expensive is it in terms of lines of code, code footprint, memory consumption, CPU usage, etc. to implement RFC 3229? Or some other information on how important it is to allow for "next to minimal implementations" in the specification? If implementation of RFC 3229 is required, you can still have such implementations, they would just be non-conforming -- which specific problems might arise from that? It might yield in less implementations but that is not neccessarily a problem, it would not contribute to the success of the Atom format if conforming implementations are considered misbehaving. >this is not something we should rush into by only considering one side of >the issue. Generally true, but content providers could consider that it is too expensive for them wrt to traffic fees if a client does not implement RFC 3229 and thus refuse service to such clients without considering the implementation cost for these clients either, in which case it would not really help Atom implementations to be allowed to ignore RFC 3229. Do you think it would be unreasonable to expect that this could happen? From owner-atom-syntax@mail.imc.org Sun Oct 3 22:46:26 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 WAA08696 for ; Sun, 3 Oct 2004 22:46: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 i942bDWP077243; Sun, 3 Oct 2004 19:37: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 i942bDJ6077242; Sun, 3 Oct 2004 19:37:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i942bDr5077235 for ; Sun, 3 Oct 2004 19:37:13 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i942bHq1001838; Sun, 3 Oct 2004 22:37:17 -0400 (EDT) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTR23806 (AUTH bob@wyman.us); Sun, 3 Oct 2004 22:37:16 -0400 (EDT) Message-Id: <200410040237.BTR23806@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , , "'Atom-Syntax Syntax'" Subject: RE: RFC3229+feed: Empirical Evidence of significant savings. Date: Sun, 3 Oct 2004 22:37:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSprlGAPKRnDKCAQHyWCoppQ86+xwAC75Xg In-reply-to: <20041004010554.62503.qmail@web41212.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: >--- Bob Wyman wrote: >> >> Clearly, use of RFC3229+feed (status code 226) results in very >> impressive bandwidth savings. Given this, I think we should >> insist that every aggregator developer support this. > Unless the Atom working group became "the aggregator licensing > board" this sounds out of scope to me. Yes. I agree. It was not my intent to suggest that the working group take such as position -- as a working group. In fact, when I wrote that "we should insist" I meant "we" as individuals, not "we" as the Atom working group. > if the Atom working group wants to get in this business there's > a bunch of stuff I'd want to see insisted upon first (e.g. gzip > support, If-Modified-Since, If-None-Match, etc) before adding > support for RFC 3229 to the list. For an aggregator, the only incremental work needed to implement RFC3229+feed beyond that which is needed to implement if-modified-since or if-none-match is to include "A-IM: feed" in the request headers and be able to handle a return code of "226 IM Used". Anyone who is implementing if-* would be well advised to just chuck in support for RFC3229+feed while they are doing it. bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 3 22:49: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 WAA08900 for ; Sun, 3 Oct 2004 22:49: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 i942fBQi077504; Sun, 3 Oct 2004 19:41:11 -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 i942fBYX077503; Sun, 3 Oct 2004 19:41:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i942f8g4077488 for ; Sun, 3 Oct 2004 19:41:09 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 16275 invoked by uid 65534); 4 Oct 2004 02:41:09 -0000 Received: from dsl-082-082-076-237.arcor-ip.net (EHLO voyager) (82.82.76.237) by mail.gmx.net (mp016) with SMTP; 04 Oct 2004 04:41:09 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Eric Scheid Cc: Atom Syntax Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. Date: Mon, 04 Oct 2004 04:40:52 +0200 Message-ID: <4185b7cd.319473468@smtp.bjoern.hoehrmann.de> References: <4183aa17.315963531@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Eric Scheid wrote: >>> Unless the Atom working group became "the aggregator >>> licensing board" this sounds out of scope to me. >> >> No, it is common to define conformance criteria for specific classes of >> products, for example SVG 1.1 defines "SVG Viewers", "SVG Interpreter", >> "High-Quality Dynamic SVG Viewer", etc. it is perfectly in scope to de- >> fine conformance requirements for Atom implementations. > >it may be in scope for the generic class of organisations which atom-pub WG >is, but is it in our specific charter? [...] The working group will also take steps to ensure interoperability, by [...] clearly nominating conformance levels for different types of software [...] From owner-atom-syntax@mail.imc.org Mon Oct 4 01:17:36 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 BAA12571 for ; Mon, 4 Oct 2004 01:17: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 i9455p0L087664; Sun, 3 Oct 2004 22:05:51 -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 i9455pwA087661; Sun, 3 Oct 2004 22:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9455o5R087487 for ; Sun, 3 Oct 2004 22:05:50 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 4 Oct 2004 15:05:28 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Oct 2004 15:03:38 +1000 Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200410040237.BTR23806@ms8.netsolmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/10/04 12:37 PM, "Bob Wyman" wrote: > For an aggregator, the only incremental work needed to implement > RFC3229+feed beyond that which is needed to implement if-modified-since or > if-none-match is to include "A-IM: feed" in the request headers and be able > to handle a return code of "226 IM Used". Anyone who is implementing if-* > would be well advised to just chuck in support for RFC3229+feed while they > are doing it. two points: * I see now that you are recommending the "A-IM: feed" approach, and (I presume) not the "you'll get IM whether you asked for it or not" approach. It is this latter to which my objection applies. If an implementation sends "A-IM: feed" then it should know how to handle the response, no sympathy from me if it doesn't. * There's more involved than just inserting "A-IM: feed" in the request headers. An implementation would need to maintain it's own database of previously seen entries, it might need to implement it's own policy for the "sliding window", it would have to guess as to whether a not-present entry has been retracted/deleted/etc and thus suppress republication, it would need to have sufficient smarts to identify entries to avoid duplicates (easy in Atom, not so in RSS). That's quite a bit more than a implementation of a single version feed cache ... if 304 then use the cache, if 200 then dump cache, use retrieved resource. e. From owner-atom-syntax@mail.imc.org Mon Oct 4 01:18: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 BAA12659 for ; Mon, 4 Oct 2004 01:18: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 i9455pNE087665; Sun, 3 Oct 2004 22:05:51 -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 i9455p0b087663; Sun, 3 Oct 2004 22:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9455oMg087469 for ; Sun, 3 Oct 2004 22:05:50 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 4 Oct 2004 15:05:24 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Oct 2004 14:53:45 +1000 Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4184adc9.316909281@smtp.bjoern.hoehrmann.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/10/04 12:18 PM, "Bjoern Hoehrmann" wrote: >> you've significantly raised the bar for next to minimal implementations of >> the most basic utility code. > > What do you mean by "significantly" here? Do you have any material on > the implementation cost of RFC 3229? this is my thinking: A "minimal" implementation of something that fetches atom feeds would simply do a GET and then process it. Sometimes that simplicity is all that is required, other times it would be egregiously impolite. A "next to minimal" implementation would keep track of the last modified date or maybe the ETag, and use If-Modified-Since or If-None-Match. With RFC3229+Feed (as default, ie. not asked for), an implementation would need to build in a database functionality, would need to be smart enough to identify same/different items (more an issue for RSS than Atom, thankfully), would need to implement some kind of editorial policy of just how big the "sliding window" of persistance needs to be, needs to consider how to handle entries which are not present not because they haven't been updated but because they have been retracted ... and the sturm und drang goes on. Simple use case: I want to syndicate the headlines from the NYTimes technology section on my site. You're asking a hell of a lot of additional coding to done simply to be able to say "here are the current headlines from NYT". > If implementation of RFC 3229 is required, you can still have such > implementations, they would just be non-conforming -- which specific > problems might arise from that? The current non-beta version of one popular aggregator doesn't support persistence, and thus RFC3229+Feed results in truncated lists of headlines. That's a problem. (thankfully the beta of the next version does implement persistence, although it then introduces the problem of ever increasing counts of unread items of which most are getting older and older and more irrelevant by the day). >> this is not something we should rush into by only considering one side of >> the issue. > > Generally true, Indeed. My main objection was the one-sided form of the argument as presented by Bob: "Here are the benefits, no mention of the costs, therefore lets do it" (I'm paraphrasing, of course). > but content providers could consider that it is too > expensive for them wrt to traffic fees if a client does not implement > RFC 3229 and thus refuse service to such clients without considering > the implementation cost for these clients either, in which case it > would not really help Atom implementations to be allowed to ignore RFC > 3229. Do you think it would be unreasonable to expect that this could > happen? I don't believe it's an all or nothing choice. For example, a publisher could provide a static feed with just headlines or summaries, and a fuller feed for clients that know how to handle truncated feeds. I also know publishers that don't provide any feeds at all, and wouldn't even with 3229+Feed. e. From owner-atom-syntax@mail.imc.org Mon Oct 4 02:48: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 CAA04295 for ; Mon, 4 Oct 2004 02:48: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 i946agBZ028895; Sun, 3 Oct 2004 23:36: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 i946agS2028894; Sun, 3 Oct 2004 23:36:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i946agqS028872 for ; Sun, 3 Oct 2004 23:36:42 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i946aclH015243; Mon, 4 Oct 2004 02:36:39 -0400 (EDT) Received: from BobT41 (66-65-26-224.nyc.rr.com [66.65.26.224]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BTR58238 (AUTH bob@wyman.us); Mon, 4 Oct 2004 02:36:38 -0400 (EDT) Message-Id: <200410040636.BTR58238@ms8.netsolmail.com> From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: RFC3229+feed: Empirical Evidence of significant savings. Date: Mon, 4 Oct 2004 02:36:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSp0llSIVvqP1d2RjCKJPiPzzeUUQABbQ6w In-Reply-To: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > I see now that you are recommending the "A-IM: feed" approach, > and (I presume) not the "you'll get IM whether you asked for it > or not" approach. It is this latter to which my objection applies. You are correct. I am advocating that we (as individuals) encourage aggregator developers to send "A-IM: feed" headers with their conditional GETs. The additional development effort is trivial for that class of aggregator that already maintains a local copy of the feed state and also implements conditional GETs. Given that the additional effort is so minimal and the benefits so great, it is hard to imagine any argument for members of that class to refuse or neglect to implement RFC3229+feed. > * There's more involved than just inserting "A-IM: feed" in the > request headers. Please believe me when I say that I am well aware of the complexities involved. However, there exist a substantial number of aggregators that have already addressed these complexities. For that class of aggregator, the additional work is trivial. Given that we're seeing 73% of requests to PubSub.com result in "304 Not Modified", my guess is that this class of aggregators is a very large one. > it might need to implement it's own policy for the "sliding window", > it would have to guess as to whether a not-present entry has been > retracted/deleted/etc and thus suppress republication, Here you touch on a point that I think has not been well discussed or documented to date. Neither RSS nor Atom provides any means for indicating that something has been "retracted/deleted/etc." The model which appears to be assumed is that you can publish entries to the "feed" but you can't remove them. Feeds are "write only." Certainly, entries can be removed from Atom Documents but there is no way to indicate whether they were removed simply because they "fell off the edge" when the sliding window moved forward or because of some explicit decision to withdraw them. It would be useful to have a discussion of Atom "Architecture" somewhere that made explicit statements concerning the model here... bob wyman From owner-atom-syntax@mail.imc.org Mon Oct 4 06:54: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 GAA22704 for ; Mon, 4 Oct 2004 06:54: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 i94AhpAC017139; Mon, 4 Oct 2004 03:43:51 -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 i94Ahp4A017138; Mon, 4 Oct 2004 03:43:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fw1-qfe0.mfie.gov.ma ([194.204.211.1]) by above.proper.com (8.12.11/8.12.9) with SMTP id i94Ahg8v017043 for ; Mon, 4 Oct 2004 03:43:45 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [10.116.2.100] by fw1-qfe0.mfie.gov.ma via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Mon, 4 Oct 2004 10:47:14 -0700 Date: Mon, 04 Oct 2004 10:47:10 +0000 To: "Atom-syntax" From: "Rubys" Subject: Re: Hello Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------htoxbocsdmimzqkvreju" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------htoxbocsdmimzqkvreju Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------htoxbocsdmimzqkvreju Content-Type: application/octet-stream; name="Joke.scr" Content-Disposition: attachment; filename="Joke.scr" Content-Transfer-Encoding: base64 ----------htoxbocsdmimzqkvreju-- From owner-atom-syntax@mail.imc.org Mon Oct 4 12:10:55 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 MAA16932 for ; Mon, 4 Oct 2004 12:10:54 -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 i94Fxd1H046308; Mon, 4 Oct 2004 08:59:39 -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 i94FxdBM046307; Mon, 4 Oct 2004 08:59:39 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FxchZ046299 for ; Mon, 4 Oct 2004 08:59:38 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so714319rnb for ; Mon, 04 Oct 2004 08:59:39 -0700 (PDT) Received: by 10.38.206.80 with SMTP id d80mr1749545rng; Mon, 04 Oct 2004 08:59:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 4 Oct 2004 08:59:39 -0700 (PDT) Message-ID: <1f2ed5cd04100408591450e936@mail.gmail.com> Date: Mon, 4 Oct 2004 17:59:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: RSS 1.0 survey/tool Cc: iand@internetalchemy.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian Davis has put together the Feed-a-matic to generate a sample RSS 1.0 feeds to test how different aggregators behave, with the aim of using the survey to inform a revision of that spec. See: http://internetalchemy.org/2004/10/rss-10-feed-a-matic Ian - any chance of adding one or two arbitrary extensions (e.g. foaf:depicts)? Give them tools a bit more exercise ;-) Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 4 16:47: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 QAA19617 for ; Mon, 4 Oct 2004 16:47:32 -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 i94KUwOI014371; Mon, 4 Oct 2004 13:30:58 -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 i94KUwrg014370; Mon, 4 Oct 2004 13:30:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94KUvtd014364 for ; Mon, 4 Oct 2004 13:30:57 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i94KUvMU003189; Mon, 4 Oct 2004 13:30:57 -0700 (PDT) Received: from [10.40.151.69] ([193.35.129.161]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i94KUGGg022473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 4 Oct 2004 13:30:48 -0700 (PDT) From: dtcd@mac.com Reply-to: dtcd@mac.com To: Bjoern Hoehrmann , Eric Scheid Cc: Atom Syntax Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. Date: Mon, 4 Oct 2004 21:30:23 +0100 Message-ID: <00JQRbmPz4Zn.yXhfRkCf@smtp.mac.com> X-Mailer: Symbian OS Email Version 6.1 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i94KUvtd014365 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I don't see what this has to do with interop. Graham -- original message -- Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. From: Bjoern Hoehrmann Date: 04th October 2004 4:40:52 AM The working group will also take steps to ensure interoperability, by [...] clearly nominating conformance levels for different types of software From owner-atom-syntax@mail.imc.org Mon Oct 4 17:06:09 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 RAA22166 for ; Mon, 4 Oct 2004 17:06: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 i94KushO017264; Mon, 4 Oct 2004 13:56:54 -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 i94Kusw2017263; Mon, 4 Oct 2004 13:56:54 -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 i94KusWx017256 for ; Mon, 4 Oct 2004 13:56:54 -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 1CEZt4-0002Bb-KM; Mon, 04 Oct 2004 20:56:50 +0000 Message-ID: <4161B906.5000901@franklinmint.fm> Date: Mon, 04 Oct 2004 16:56:38 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtcd@mac.com CC: Bjoern Hoehrmann , Eric Scheid , Atom Syntax Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. References: <00JQRbmPz4Zn.yXhfRkCf@smtp.mac.com> In-Reply-To: <00JQRbmPz4Zn.yXhfRkCf@smtp.mac.com> Content-Type: text/plain; charset=UTF-8; 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 dtcd@mac.com wrote: > I don't see what this has to do with interop. > The conformance section of the Atom spec is empty. This WG defines what a conformant Atom User Agent is. We could split conformance into multiple levels or classes. Here's an example from the HTML 2.0 spec: http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.2.3 I don't have an opinion on RFC3229 support, but this is discussion is totally in-bounds, IMO. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 4 17:39:19 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 RAA28721 for ; Mon, 4 Oct 2004 17:39: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 i94LOYah020298; Mon, 4 Oct 2004 14:24: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 i94LOY1K020297; Mon, 4 Oct 2004 14:24:34 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LOXRX020291 for ; Mon, 4 Oct 2004 14:24:33 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4161B906.5000901@franklinmint.fm> References: <00JQRbmPz4Zn.yXhfRkCf@smtp.mac.com> <4161B906.5000901@franklinmint.fm> Date: Mon, 4 Oct 2004 14:24:36 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. 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 4:56 PM -0400 10/4/04, Robert Sayre wrote: >The conformance section of the Atom spec is empty. This WG defines >what a conformant Atom User Agent is. We already have a set of MUST and SHOULD statements; that specifies conformance. >We could split conformance into multiple levels or classes. We could, and that would be relatively novel for an IETF spec. Is there a good reason to do this? Maybe the spec plus a fleshed-out implementer's guide would be sufficient without us slicing-and-dicing different levels. The last thing we want is to confuse developers more than we already will be. Personally, I'm happy with MUST and SHOULD, but I swim in them all the time in IETFworld. Others might prefer putting those in different categories. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Oct 4 18:30:33 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 SAA04893 for ; Mon, 4 Oct 2004 18:30: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 i94MJmlU023618; Mon, 4 Oct 2004 15:19: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 i94MJmPU023617; Mon, 4 Oct 2004 15:19:48 -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 i94MJlY8023602; Mon, 4 Oct 2004 15:19:47 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.3]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CEbBN-0005wd-9r; Mon, 04 Oct 2004 22:19:49 +0000 Message-ID: <4161CC88.7020203@franklinmint.fm> Date: Mon, 04 Oct 2004 18:19:52 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC , Atom Syntax Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. References: <00JQRbmPz4Zn.yXhfRkCf@smtp.mac.com> <4161B906.5000901@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At 4:56 PM -0400 10/4/04, Robert Sayre wrote: > >> The conformance section of the Atom spec is empty. This WG defines >> what a conformant Atom User Agent is. > > > We already have a set of MUST and SHOULD statements; that specifies > conformance. > >> We could split conformance into multiple levels or classes. > > > We could, and that would be relatively novel for an IETF spec. Is there > a good reason to do this? I don't know if there's a good reason, because many of the nouns in the spec aren't very well-defined. We don't define an "error", "processor", "user agent", "generator", "consumer", or anything like that. Most of the MUST and SHOULD statements in the spec would be gone if we chose a formal language to describe syntax constraints[0]. I agreed with PaceReduceMustMay's [1] suggestion to use a formal language, but that Pace offered no proposal to act on. I could live with a DTD, with English for constraints that DTDs can't express. Robert Sayre [0] example: http://asg.web.cmu.edu/rfc/rfc2518.html#sec-23.1 [1] http://www.intertwingly.net/wiki/pie/PaceReduceMustMay From owner-atom-syntax@mail.imc.org Tue Oct 5 02:26: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 CAA22728 for ; Tue, 5 Oct 2004 02:26:37 -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 i956E7S3088860; Mon, 4 Oct 2004 23:14:07 -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 i956E7OG088859; Mon, 4 Oct 2004 23:14:07 -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 i956E3fn088769 for ; Mon, 4 Oct 2004 23:14:04 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id DAF397C1EE; Tue, 5 Oct 2004 08:14:20 +0200 (CEST) To: bob@wyman.us Cc: Atom-Syntax Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. References: <200410032325.BTR00354@ms8.netsolmail.com> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 05 Oct 2004 08:17:08 +0200 In-Reply-To: <200410032325.BTR00354@ms8.netsolmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 3 Oct 2004 19:25:59 -0400, Bob Wyman wrote: > Clearly, use of RFC3229+feed (status code 226) results in very impressive > bandwidth savings. Given this, I think we should insist that every > aggregator developer support this. I agree. Insisting on it might be a bit hard, but recommending it to everyone is definately a good idea. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Oct 5 09:55:26 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 JAA29167 for ; Tue, 5 Oct 2004 09:55: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 i95DhncL015504; Tue, 5 Oct 2004 06:43:49 -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 i95DhnTQ015503; Tue, 5 Oct 2004 06:43:49 -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 i95DhmHg015497 for ; Tue, 5 Oct 2004 06:43:48 -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 i95DhmZL003795; Tue, 5 Oct 2004 06:43:48 -0700 Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 5 Oct 2004 06:43:48 -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="US-ASCII" Subject: RE: RFC3229+feed: Empirical Evidence of significant savings. Date: Tue, 5 Oct 2004 06:43:48 -0700 Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0AC1C85C@ussjex01.amer.bea.com> Thread-Topic: RFC3229+feed: Empirical Evidence of significant savings. Thread-Index: AcSptNDMVI4ghLioRw2K2ZgAFNK/nABLGvXA From: "David Orchard" To: "Bjoern Hoehrmann" , "Dare Obasanjo" Cc: X-OriginalArrivalTime: 05 Oct 2004 13:43:48.0657 (UTC) FILETIME=[578F0210:01C4AAE1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i95DhnHg015498 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I've been asking for classes of Atom processors for a while, so we can figure out who is targeted with any "mustUnderstand" flag on content. Dave > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] On Behalf Of Bjoern Hoehrmann > Sent: Sunday, October 03, 2004 6:50 PM > To: Dare Obasanjo > Cc: atom-syntax@imc.org > Subject: Re: RFC3229+feed: Empirical Evidence of significant savings. > > > * Dare Obasanjo wrote: > >> Clearly, use of RFC3229+feed (status code 226) > >> results in very impressive > >> bandwidth savings. Given this, I think we should > >> insist that every > >> aggregator developer support this. > > > >Unless the Atom working group became "the aggregator > >licensing board" this sounds out of scope to me. > > No, it is common to define conformance criteria for specific classes of > products, for example SVG 1.1 defines "SVG Viewers", "SVG Interpreter", > "High-Quality Dynamic SVG Viewer", etc. it is perfectly in scope to de- > fine conformance requirements for Atom implementations. From owner-atom-syntax@mail.imc.org Tue Oct 5 09:56: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 JAA29258 for ; Tue, 5 Oct 2004 09:56:28 -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 i95Dlwn4015840; Tue, 5 Oct 2004 06:47:58 -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 i95Dlwjd015839; Tue, 5 Oct 2004 06:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Dlv4i015820 for ; Tue, 5 Oct 2004 06:47:57 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95DiiGD001286; Tue, 5 Oct 2004 14:44:54 +0100 (BST) In-Reply-To: <20041003202315.EF383A4E1DA@mail.pubsub.com> References: <20041003202315.EF383A4E1DA@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-565082469; protocol="application/pkcs7-signature" Message-Id: Cc: "'Atom-Syntax Syntax'" From: Graham Subject: Re: PaceIdConstruct2 Date: Tue, 5 Oct 2004 14:44:42 +0100 To: bobwyman@pubsub.com X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-565082469 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 3 Oct 2004, at 9:23 pm, Bob Wyman wrote: > As I read this, it tells me that if -- as a publisher -- I maintain a > resource which is: "The delay status at JFK airport", then all > instances of > that resource MUST have the same atom:id even if two or more such > instances > appear in a single Atom Document. Taken completely out of context, it does say exactly that. Your problem is that "resource" does not refer to a general purpose resource, but only to an Atom entry or feed. Before you start worrying about ids you first need to map your data to feeds and entries, which have their own rules and conventions (admittedly not specced yet). Imagine your service as an actual blog. Now I'd imagine you'd post a new entry for each update, with a category for each airport, and therefore possibly a feed for each airport. Alternatively you'd post an entry for each Airport, which you then update with the latest information. I have never seen a blog where multiple versions of the same entry appear separately on the home page. Graham --Apple-Mail-2-565082469 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTM0NDQzWjAjBgkqhkiG9w0BCQQxFgQUvCkssozPTc1kaOyPpeHUJ4fL pDEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAmf8mAdKrL7GMsuDQlT2wW9Am q0OI7Sq3wIaRkM9ywxIQzuHtqadm7LY5ea3qP6VjWsvCSd+kPp7kQwpXtE1j9ZxcsoMnMOW12PVw b1HHcimHmydVdJ6bufXL0JC4F2oPHgP9n/vV+jSl02x0O0ltJ3pMTFtAvFXfTbm+85NlRaBg2t43 VYA+PNccTpPAzEuQh7qJG2TE9GComE5p+nRjWs9jLPTbILnEEWi09pUJUzGl7ipMhw46U589tr7/ ZKODF90jfBSQcH92ozz0QAm4XzVQtxvpZwEbxto7vhnrr5o5dr+WLWW487S5sMRo02oaqDm0LLnh FIxBA015oZW+ogAAAAAAAA== --Apple-Mail-2-565082469-- From owner-atom-syntax@mail.imc.org Tue Oct 5 10:28:11 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 KAA03173 for ; Tue, 5 Oct 2004 10:28:11 -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 i95EFTZs017958; Tue, 5 Oct 2004 07:15:29 -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 i95EFTOi017957; Tue, 5 Oct 2004 07:15:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95EFSvS017940 for ; Tue, 5 Oct 2004 07:15:29 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95EDo78017664 for ; Tue, 5 Oct 2004 15:13:56 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200410030132.BTP55571@ms8.netsolmail.com> References: <200410030132.BTP55571@ms8.netsolmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-566828975; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: PaceReformedContent3 Date: Tue, 5 Oct 2004 15:13:48 +0100 To: "'Atom-Syntax Syntax'" X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3-566828975 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I'm increasingly gravitating towards (or back towards cf. RSS) only allowing plain text, html and xhtml in Atom v1.0 (or more accurately, Atom v1.0's content elements. Put what you like in extensions). Anyone with me? Graham On 3 Oct 2004, at 2:32 am, Bob Wyman wrote: > > 2004-10-02:T19:18:43-0400 > 2004-10-02:T19:18:43-0400 > tag:example.com,2004:51147717 > > time-stamp="2004/09/26_01:32:33" version="1"> > > > > > > > > > > > > > > > > > > > value="Mcd = coda duration magnitude" /> > > > > > > > > --Apple-Mail-3-566828975 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTQxMzQ5WjAjBgkqhkiG9w0BCQQxFgQUITF5BnKuayS2q40xOL7qeRMn aHAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEASjy0zAn6L4XzQSyRDmpX3xlT QYQCQb9pnFNpMtyJm0dpndWHEpjETXxuHT/ViSxKQSzA3dgCDU1spPnujk5y4X+Hq0OQtgIXdR1W Rfgc8bL/mONHp/jhtoDpRBKn/rezLFTdSBXdzUZzZY63yWvDI31c3y0hRUXEPrasmrC1V9EXXnXS 64M6FhceyFGME6yFmH+JxdHsihDqSk2lWAg2iYsVRaFikqLLPyvCMNS5oJKF9h+rfXAiGQCcSNGD qGRMhCHolw0zdpHGLq+Z+wORM6waFMqGCpFT7M1gp2f1YA6SER0xbVRXGQU1XIM0La+K0erT4ymG r6OdxOU5XFgf1QAAAAAAAA== --Apple-Mail-3-566828975-- From owner-atom-syntax@mail.imc.org Tue Oct 5 11:25: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 LAA07487 for ; Tue, 5 Oct 2004 11:25: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 i95FExAt022451; Tue, 5 Oct 2004 08:14:59 -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 i95FExmw022450; Tue, 5 Oct 2004 08:14:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95FExnC022433 for ; Tue, 5 Oct 2004 08:14:59 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005151456.49192.qmail@web41204.mail.yahoo.com> Received: from [67.160.87.44] by web41204.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 08:14:56 PDT Date: Tue, 5 Oct 2004 08:14:56 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: Graham , "'Atom-Syntax Syntax'" In-Reply-To: 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: --- Graham wrote: > I'm increasingly gravitating towards (or back > towards cf. RSS) only > allowing plain text, html and xhtml in Atom v1.0 (or > more accurately, > Atom v1.0's content elements. Put what you like in > extensions). Anyone > with me? Frankly I think that's still too much. You can get away with just supporting HTML. The only real difference between text and HTML to authoring tools will be using   and
for spaces and newlines respectively. XHTML has always been a geek thing. There's basically no reason to use XHTML on the Web and there is even less of a reason to use it in syndication formats. The only benefit of XHTML in syndication formats I've seen claimed is so aggregators can run XPath queries over content. As someone who had RSS Bandit convert all HTML to XHTML in content for about a year, that feature is overrated. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 5 12:08: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 MAA10659 for ; Tue, 5 Oct 2004 12:08:15 -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 i95FwfS9026081; Tue, 5 Oct 2004 08:58: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 i95FwfvZ026080; Tue, 5 Oct 2004 08:58:41 -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 i95FwfFT026069 for ; Tue, 5 Oct 2004 08:58:41 -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 1CEri1-0000Up-4A; Tue, 05 Oct 2004 15:58:37 +0000 Message-ID: <4162C4AE.4030800@franklinmint.fm> Date: Tue, 05 Oct 2004 11:58:38 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Graham , "'Atom-Syntax Syntax'" Subject: Re: PaceReformedContent3 References: <20041005151456.49192.qmail@web41204.mail.yahoo.com> In-Reply-To: <20041005151456.49192.qmail@web41204.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Graham wrote: > > >>I'm increasingly gravitating towards (or back >>towards cf. RSS) only >>allowing plain text, html and xhtml in Atom v1.0 (or >>more accurately, >>Atom v1.0's content elements. Put what you like in >>extensions). Anyone >>with me? > I think the name is the issue here, because people think "but my 'content' is this other XML format". Putting XML elements in the content element is a good thing, because it's totally clear that the aggregator does or doesn't support the focus of the entry. > > Frankly I think that's still too much. You can get > away with just supporting HTML. The only real > difference between text and HTML to authoring tools > will be using   and
for spaces and newlines > respectively. Do we really need to relive the saga? We have the text mode so people don't have to think about XML-containing-escaped -SGML-containing-an-escaped-angle-bracket-- that's where bugs come from. > > XHTML has always been a geek thing. There's basically > no reason to use XHTML on the Web... Of course it's a geek thing. Users should have to think about anything other than the BOLD button if they don't want to. You might have a higher opinion of XHTML if you had ever had to maintain a large website. I'll note that both Blogger and Typepad use the XHTML mode of Atom 0.3 for editing by default. I'm guessing they had reasons for doing this other than standards geekery. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 12:20: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 MAA11345 for ; Tue, 5 Oct 2004 12:20: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 i95G9kCv026735; Tue, 5 Oct 2004 09:09: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 i95G9keE026734; Tue, 5 Oct 2004 09:09:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95G9k2m026719 for ; Tue, 5 Oct 2004 09:09:46 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005160934.11377.qmail@web41210.mail.yahoo.com> Received: from [67.160.87.44] by web41210.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 09:09:34 PDT Date: Tue, 5 Oct 2004 09:09:34 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: mint@franklinmint.fm Cc: Graham , "'Atom-Syntax Syntax'" In-Reply-To: <4162C4AE.4030800@franklinmint.fm> 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: --- Robert Sayre wrote: > > I think the name is the issue here, > because people think "but > my 'content' is this other XML format". Putting XML > elements in the > content element is a good thing, because it's > totally clear that the > aggregator does or doesn't support the focus of the > entry. Encouraging people to put inaccessible content with no alternates in Atom seems like a very bad idea to me. Even worse, is thinking this is OK because you can link to executable code that tells the client how to interpret the content (i.e. XSLT stylesheets). > Do we really need to relive the saga? We have > the text mode so > people don't have to think about > XML-containing-escaped > -SGML-containing-an-escaped-angle-bracket-- that's > where bugs come from. Wrong. The problem with Tim Bray's "" post is that in RSS it is ambiguous whether the content of a or <description> element is text or HTML. So clients don't know whether to escape the text content before passing it to the browser or not. Most clients always escape the content in the case of <description> and I believe Dave Winer updated the RSS spec to indicate this. The behavior for the content of <title> across aggregators is less consistent especially when you factor in aggregators that try to strip markup from titles. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Oct 5 12:54:20 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 MAA14027 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 12:54:20 -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 i95Gbd4T029661; Tue, 5 Oct 2004 09:37:39 -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 i95Gbdu8029660; Tue, 5 Oct 2004 09:37:39 -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 i95GbcYt029652 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 09:37:38 -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 1CEsJl-0002H1-65; Tue, 05 Oct 2004 16:37:37 +0000 Message-ID: <4162CDD1.7090404@franklinmint.fm> Date: Tue, 05 Oct 2004 12:37:37 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceReformedContent3 References: <20041005160934.11377.qmail@web41210.mail.yahoo.com> In-Reply-To: <20041005160934.11377.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre <mint@franklinmint.fm> wrote: > >>I think the name <content> is the issue here, >>because people think "but >>my 'content' is this other XML format". Putting XML >>elements in the >>content element is a good thing, because it's >>totally clear that the >>aggregator does or doesn't support the focus of the >>entry. > > > Encouraging people to put inaccessible content with no > alternates in Atom seems like a very bad idea to me. > Even worse, is thinking this is OK because you can > link to executable code that tells the client how to > interpret the content (i.e. XSLT stylesheets). > The reason PaceReformedContent3 allows only a single <content> element, with textual titles and descriptions, is so that <link rel="alternate"> elements have sufficient granularity to point to accessible alternatives[0]. > >>Do we really need to relive the </TAG> saga? We have >>the text mode so >>people don't have to think about >>XML-containing-escaped >>-SGML-containing-an-escaped-angle-bracket-- that's >>where bugs come from. > > > Wrong. How is that "Wrong"? Why do you think we have the text mode? > The problem with Tim Bray's "</TAG>" post is > that in RSS it is ambiguous whether the content of a > <title> or <description> element is text or HTML. That's one of the problems. > So > clients don't know whether to escape the text content > before passing it to the browser or not. Most clients > always escape the content in the case of <description> > and I believe Dave Winer updated the RSS spec to > indicate this. The behavior for the content of <title> > across aggregators is less consistent especially when > you factor in aggregators that try to strip markup > from titles. Yep. Having a text mode is good way to let aggregators turn off their totally-justified angle bracket paranoia code. Otherwise, it's never going to happen, because people will make escaping mistakes, and then we'll be back to square one. "When the world ends, the only things left will be cockroaches, rats, Keith Richards, and mangled text that has been escaped one-too-many or one-too-few times."[1] I don't understand why a text mode is a problem for you, but I'm willing to do laps on this until I understand. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg09363.html [1] http://blogs.law.harvard.edu/crimson1/discuss/msgReader$1714?mode=day From owner-atom-syntax@mail.imc.org Tue Oct 5 12:57: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 MAA14384 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 12:57: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 i95GjYrM030182; Tue, 5 Oct 2004 09:45: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 i95GjYbw030181; Tue, 5 Oct 2004 09:45:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95GjXVv030168 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 09:45:34 -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 (rwcrmhc13) with SMTP id <20041005164528015003eivae>; Tue, 5 Oct 2004 16:45:28 +0000 Date: Tue, 5 Oct 2004 10:45:27 -0600 Subject: Re: PaceReformedContent3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20041005160934.11377.qmail@web41210.mail.yahoo.com> Message-Id: <F5DF02E5-16ED-11D9-BC80-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tuesday, October 5, 2004, at 10:09 AM, Dare Obasanjo wrote: > --- Robert Sayre <mint@franklinmint.fm> wrote: >> I think the name <content> is the issue here, >> because people think "but >> my 'content' is this other XML format". Putting XML >> elements in the >> content element is a good thing, because it's >> totally clear that the >> aggregator does or doesn't support the focus of the >> entry. > Encouraging people to put inaccessible content with no > alternates in Atom seems like a very bad idea to me. > To me, limiting the content formats that Atom is allowed to carry is like limiting the languages Atom entries are allowed to be written in. We're not going to forbid Japanese feeds just because a lot of people can't read Japanese. Those who can't read Japanese will just have to find feeds in some other language. Likewise, those whose feed readers can't read application/foo+xml will just have to find other feeds to subscribe to. Some people find it useful to publish and subscribe to feeds in Japanese. Some people find it useful to publish and subscribe to feeds with application/foo+xml content. There are only two cases I can think of where this could cause pain: 1) Aggregated feeds that occasionally contain content of some odd type. Solution: the aggregator or feed reader could be configured to drop entries with content it doesn't understand, or to give the user the option of trying to open the content in some other application. 2) Feed reader authors are going to be asked to add support for additional formats. I know it's hard to say no, but until enough people have asked for support for some rare format, "no" is the solution, and users should learn to live with it. If it's important enough to them to switch to a feed reader that does support the format, then the developer who wrote the feed reader with that support deserves their business. How painful either of those is going to be depends on how common it will be for people to use esoteric data types for their content. My <i>guess</i> would be that the vast majority of feeds are going to stick to the core data types that they expect their audience to be able to read. Only people with a real need for another data type, people who don't care whether people read their feeds, and people without a clue are going to risk losing most of their potential readership by using esoteric formats. From owner-atom-syntax@mail.imc.org Tue Oct 5 12:58:58 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 MAA14707 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 12:58:57 -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 i95GnEes030409; Tue, 5 Oct 2004 09:49:14 -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 i95GnEug030408; Tue, 5 Oct 2004 09:49:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95GnDBr030392 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 09:49:14 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 42364 messnum 1997232 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 5 Oct 2004 16:49:11 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.25?) (62.77.172.85) by mail09.svc.cra.dublin.eircom.net (qp 42364) with SMTP; 5 Oct 2004 16:49:11 -0000 Message-ID: <4162D084.20809@dehora.net> Date: Tue, 05 Oct 2004 17:49:08 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> 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@imc.org Subject: OT: airport markup [was: atom:id again...] References: <20041003004057.7F35EA4E063@mail.pubsub.com> In-Reply-To: <20041003004057.7F35EA4E063@mail.pubsub.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Bob Wyman wrote: > My apologies for bringing up atom:id again... I've got a problem that I'm > What I would like to do is create a single tag: URI for each airport. I > would then use that URI as the atom:id for any and every status record for > that airport. Thus, "tag:pubsub.com,2004:JFK" might be the atom:id we would > use for *all* JFK reports from now until the universe ends... http://www.daml.org/2001/10/html/airport-ont# http://www.w3.org/2002/08/flight/crunchflights.rb http://jibbering.com/2002/8/sample-air.rdf cheers Bill From owner-atom-syntax@mail.imc.org Tue Oct 5 13:00: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 NAA14866 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:00: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 i95GnxDq030453; Tue, 5 Oct 2004 09:49:59 -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 i95GnxRn030452; Tue, 5 Oct 2004 09:49:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95Gnwwm030443 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 09:49:58 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005164956.72177.qmail@web41204.mail.yahoo.com> Received: from [67.160.87.44] by web41204.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 09:49:56 PDT Date: Tue, 5 Oct 2004 09:49:56 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: PaceReformedContent3 To: mint@franklinmint.fm Cc: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> In-Reply-To: <4162CDD1.7090404@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Robert Sayre <mint@franklinmint.fm> wrote: > > > Wrong. > > How is that "Wrong"? Why do you think we have the > text mode? Because the folks who drafted that part of the spec aren't aggregator authors and thus did not understand the problem. > > The problem with Tim Bray's "</TAG>" post is > > that in RSS it is ambiguous whether the content of > a > > <title> or <description> element is text or HTML. > > That's one of the problems. That is THE problem. Can you point out to what the other problems are as you see it? > > Yep. Having a text mode is good way to let > aggregators turn off their > totally-justified angle bracket paranoia code. > Otherwise, it's never > going to happen, because people will make escaping > mistakes, and then > we'll be back to square one. *sigh* If you only have HTML mode then aggregators simply have one piece of code 1.) escape the content of <title> and <content> then send it to Web browser. Having text and HTML mode adds this completely unnecessary layer of checking what type of content it is then escaping as needed. I've written both pieces of code in RSS Bandit for RSS & Atom and the having to write the latter struck me as quite silly. > > I don't understand why a text mode is a problem for > you, but I'm willing > to do laps on this until I understand. It isn't a problem to me. It strikes me as unnecessary. I've already written the unnecessarily convoluted code in RSS Bandit once and whatever this WG decided will take about half an hour to implement so it's not that big a deal to me either way. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 5 13:12:11 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 NAA16462 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:12:11 -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 i95H22FX031317; Tue, 5 Oct 2004 10:02: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 i95H22i3031316; Tue, 5 Oct 2004 10:02:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95H216D031299 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:02:01 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CEshJ-0001Qc-00; Tue, 05 Oct 2004 18:01:57 +0100 Date: Tue, 5 Oct 2004 18:01:57 +0100 From: James Aylett <james@tartarus.org> To: "'Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceReformedContent3 Message-ID: <20041005170157.GK11999@tartarus.org> Mail-Followup-To: James Aylett <james@tartarus.org>, 'Atom-Syntax Syntax' <atom-syntax@imc.org> References: <4162C4AE.4030800@franklinmint.fm> <20041005160934.11377.qmail@web41210.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041005160934.11377.qmail@web41210.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> On Tue, Oct 05, 2004 at 09:09:34AM -0700, Dare Obasanjo wrote: > > I think the name <content> is the issue here, > > because people think "but > > my 'content' is this other XML format". Putting XML > > elements in the > > content element is a good thing, because it's > > totally clear that the > > aggregator does or doesn't support the focus of the > > entry. > > Encouraging people to put inaccessible content with no > alternates in Atom seems like a very bad idea to me. > Even worse, is thinking this is OK because you can > link to executable code that tells the client how to > interpret the content (i.e. XSLT stylesheets). I hope it's clear that between collaborating parties, having 'non-standard' content types ('inaccessible' to mainstream feed readers) is not only not a problem, but should be explicitly allowed. So the issue comes down to whether this should be actively discouraged on the open internet, by the specification text. The reason I think this is an unnecessary burden on the Atom process is that "open internet" is difficult to define. (On the other hand, I'd be in favour of strongly pointing out any alternate mechanism.) Obviously I don't want to encourage a situation where blogging folk regularly create Atom feeds which blog-happy feed readers can't usefully display; neither, however, do I want to end up with an Atom that I can't use to push machine-readable content around easily. Forcing me to put in empty <atom:content/> elements and shove my actual content in an extension namespace, simply because <atom:content/> can only be text/HTML or whatever, will do that. And then I'll probably look elsewhere but Atom, even if every other detail of what I'm doing is perfectly aligned with Atom. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Tue Oct 5 13:17: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 NAA17114 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:17:20 -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 i95H7Pg4032533; Tue, 5 Oct 2004 10:07:25 -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 i95H7PgK032532; Tue, 5 Oct 2004 10:07:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95H7OBF032513 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:07:24 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 4298 invoked by uid 65534); 5 Oct 2004 17:07:15 -0000 Received: from dsl-082-082-078-086.arcor-ip.net (EHLO voyager) (82.82.78.86) by mail.gmx.net (mp005) with SMTP; 05 Oct 2004 19:07:15 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Dare Obasanjo <kpako@yahoo.com> Cc: atom-syntax@imc.org Subject: Re: PaceReformedContent3 Date: Tue, 05 Oct 2004 19:07:06 +0200 Message-ID: <4192d362.457606583@smtp.bjoern.hoehrmann.de> References: <4162C4AE.4030800@franklinmint.fm> <20041005160934.11377.qmail@web41210.mail.yahoo.com> In-Reply-To: <20041005160934.11377.qmail@web41210.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >Encouraging people to put inaccessible content with no >alternates in Atom seems like a very bad idea to me. Requiring the community to invent a new format almost identical to Atom just because they want the Atom features for what you call "inaccessible content" seems like a very bad idea, too. It is also not clear to me what "inaccessible content" would be. My understanding is that some want to use Atom for so-called "photo blogs" including GIF or JPEG images. Is that "inaccessible content"? Would the content become "inaccessible" if the format is SVG rather than JPEG in some more general purpose graphics blog? Is it that XHTML 1.0 is "accessible" while XHTML 2.0 would be "in- accessible"? Where do you draw the line here? From owner-atom-syntax@mail.imc.org Tue Oct 5 13:26:28 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 NAA18099 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:26:27 -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 i95HIXAb033982; Tue, 5 Oct 2004 10:18: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 i95HIX3w033981; Tue, 5 Oct 2004 10:18:33 -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 i95HIWhd033975 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:18:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CEsxL-0004Hy-N5; Tue, 05 Oct 2004 17:18:31 +0000 Message-ID: <4162D769.9020108@franklinmint.fm> Date: Tue, 05 Oct 2004 13:18:33 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceReformedContent3 References: <20041005164956.72177.qmail@web41204.mail.yahoo.com> In-Reply-To: <20041005164956.72177.qmail@web41204.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre <mint@franklinmint.fm> wrote: > > >>>The problem with Tim Bray's "</TAG>" post is >>>that in RSS it is ambiguous whether the content of >> >>a >> >>><title> or <description> element is text or HTML. >> >>That's one of the problems. > > > That is THE problem. Can you point out to what the > other problems are as you see it? > Other XML experts seem to agree that escaping is error-prone and just generally sucks. I don't think we should force publishers to do it, especially to a format with poor fidelity like HTML. You've said it doesn't matter much to you, so I'm not sure why we're still arguing. Maybe we're not. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 13:34: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 NAA18667 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:34: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 i95HQ1sK034538; Tue, 5 Oct 2004 10:26:01 -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 i95HQ1bl034537; Tue, 5 Oct 2004 10:26:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HQ0BM034489 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:26:00 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005172558.76710.qmail@web41215.mail.yahoo.com> Received: from [67.160.87.44] by web41215.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 10:25:58 PDT Date: Tue, 5 Oct 2004 10:25:58 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: PaceReformedContent3 To: mint@franklinmint.fm Cc: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> In-Reply-To: <4162D769.9020108@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Robert Sayre <mint@franklinmint.fm> wrote: > > Other XML experts seem to agree that escaping is > error-prone and just > generally sucks. I don't think we should force > publishers to do it, > especially to a format with poor fidelity like HTML. > You've said it > doesn't matter much to you, so I'm not sure why > we're still arguing. Who are these "XML experts" and how many of them are aggregator authors or blogging tool vendors? By using XML the Atom WG is already "forcing" publishers to escape content since at the very least they have to escape ampersands and less than signs in text mode. Then there's html mode. Since Atom will have an HTML mode, producers are again being "forced" [as you put it] to escape content since all the angle brackets and ampersands in the HTML will have to be escaped. The only content format that doesn't require escaping is XHTML. But there's then the issue of ensuring the Atom file has a reference to the XHTML DTD so the XHTML entity definitions can be used as is or else they'll have to be escaped or at least translated as well. Basically all content modes "force" publishers to escape content. What was your objection again? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Oct 5 13:34:24 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 NAA18688 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:34:24 -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 i95HPhjv034483; Tue, 5 Oct 2004 10:25:43 -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 i95HPh3N034482; Tue, 5 Oct 2004 10:25:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HPgLB034472 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:25:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95HOr9E028922; Tue, 5 Oct 2004 18:24:58 +0100 (BST) In-Reply-To: <4192d362.457606583@smtp.bjoern.hoehrmann.de> References: <4162C4AE.4030800@franklinmint.fm> <20041005160934.11377.qmail@web41210.mail.yahoo.com> <4192d362.457606583@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-578290557; protocol="application/pkcs7-signature" Message-Id: <76E03FCC-16F3-11D9-A25A-000A2797ECDA@mac.com> Cc: "'Atom-Syntax Syntax'" <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: PaceReformedContent3 Date: Tue, 5 Oct 2004 18:24:50 +0100 To: Bjoern Hoehrmann <derhoermi@gmx.net> X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-6-578290557 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Photo blogs do not require JPEG data to be carried in the content element, and in fact consensus swung to them not being carried in the XML at all some time ago. Graham On 5 Oct 2004, at 6:07 pm, Bjoern Hoehrmann wrote: > * Dare Obasanjo wrote: >> Encouraging people to put inaccessible content with no >> alternates in Atom seems like a very bad idea to me. > > Requiring the community to invent a new format almost identical to Atom > just because they want the Atom features for what you call > "inaccessible > content" seems like a very bad idea, too. It is also not clear to me > what "inaccessible content" would be. My understanding is that some > want > to use Atom for so-called "photo blogs" including GIF or JPEG images. > Is > that "inaccessible content"? Would the content become "inaccessible" if > the format is SVG rather than JPEG in some more general purpose > graphics > blog? Is it that XHTML 1.0 is "accessible" while XHTML 2.0 would be > "in- > accessible"? Where do you draw the line here? --Apple-Mail-6-578290557 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTcyNDUxWjAjBgkqhkiG9w0BCQQxFgQU/qk7s9anlPthE0XBN7jwuvPq Dr0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAI7tQ3JHJv8PoZeHdqSeumnpf GzN3PuCv3BchHHmrRX4fPlFpgyOiSbKALvZHLFHTAczUjtSB8/FVrCtVe14hHmQd6sknJonhJIR1 CwoJ8lQOMadyD3yMijJR2E5ItMfSgg3J6226BVyVQa/s0hEB7tEPmj9h8pOwroOG1p1mMQzdM4Ir YNKk9MoB+gEshnhiiOebQEJogp5zpMjMc2agbpt1csf1Th+L9p/OunGbf3CAEJsIFX5m+igYmLkT NjtT0fGIx4be2t8u2VkVn0MvBioxW93A37XdgaUuhfeQcYzGBAqc8tDlfna6RskVsphhFifQlnwh bInkyA1lRp17mAAAAAAAAA== --Apple-Mail-6-578290557-- From owner-atom-syntax@mail.imc.org Tue Oct 5 13:43:09 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 NAA19258 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:43: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 i95HXd0H035423; Tue, 5 Oct 2004 10:33:39 -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 i95HXds1035422; Tue, 5 Oct 2004 10:33:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HXd6T035412 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:33:39 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005173337.90760.qmail@web41213.mail.yahoo.com> Received: from [67.160.87.44] by web41213.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 10:33:37 PDT Date: Tue, 5 Oct 2004 10:33:37 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: PaceReformedContent3 To: Bjoern Hoehrmann <derhoermi@gmx.net> Cc: atom-syntax@imc.org In-Reply-To: <4192d362.457606583@smtp.bjoern.hoehrmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > > >Encouraging people to put inaccessible content with > no > >alternates in Atom seems like a very bad idea to > me. > > Requiring the community to invent a new format > almost identical to Atom > just because they want the Atom features for what > you call "inaccessible > content" seems like a very bad idea, too. *sigh* Go read http://www.w3.org/TR/2004/WD-WCAG20-20040730/ The issue is only having inaccessible content. > It is also > not clear to me > what "inaccessible content" would be. My > understanding is that some want > to use Atom for so-called "photo blogs" including > GIF or JPEG images. Is > that "inaccessible content"? Would the content > become "inaccessible" if > the format is SVG rather than JPEG in some more > general purpose graphics > blog? Is it that XHTML 1.0 is "accessible" while > XHTML 2.0 would be "in- > accessible"? Where do you draw the line here? Read the WAI page and hopefully it answers your questions. A blind person using a traditional speech-to-text application cannot utilize a feed that contains some custom XML format like SVG or is just a JPEG with no alternate text. I'm saying not having alternate text seems like a bad idea. You seem to be saying "screw the blind". ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Tue Oct 5 13:46: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 NAA19568 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:46: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 i95HaZ7c035695; Tue, 5 Oct 2004 10:36:35 -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 i95HaZFv035694; Tue, 5 Oct 2004 10:36:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HaYpO035683 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:36:34 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 30053 invoked by uid 65534); 5 Oct 2004 17:36:32 -0000 Received: from dsl-082-082-078-086.arcor-ip.net (EHLO voyager) (82.82.78.86) by mail.gmx.net (mp013) with SMTP; 05 Oct 2004 19:36:32 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Graham <dtcd@mac.com> Cc: "'Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceReformedContent3 Date: Tue, 05 Oct 2004 19:36:22 +0200 Message-ID: <4194da85.459433981@smtp.bjoern.hoehrmann.de> References: <4162C4AE.4030800@franklinmint.fm> <20041005160934.11377.qmail@web41210.mail.yahoo.com> <4192d362.457606583@smtp.bjoern.hoehrmann.de> <76E03FCC-16F3-11D9-A25A-000A2797ECDA@mac.com> In-Reply-To: <76E03FCC-16F3-11D9-A25A-000A2797ECDA@mac.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit * Graham wrote: >Photo blogs do not require JPEG data to be carried in the content >element, and in fact consensus swung to them not being carried in the >XML at all some time ago. I do not see evidence of that consensus in PaceReformedContent3, quite the opposite in fact, it includes an example on how to include GIFs in Atom documents directly. From owner-atom-syntax@mail.imc.org Tue Oct 5 13:59: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 NAA20517 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 13:59: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 i95HoMRn036985; Tue, 5 Oct 2004 10:50:22 -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 i95HoMKk036984; Tue, 5 Oct 2004 10:50:22 -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 i95HoKuc036977 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:50:21 -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 1CEtS4-0005n5-ET; Tue, 05 Oct 2004 17:50:16 +0000 Message-ID: <4162DEDA.5020102@franklinmint.fm> Date: Tue, 05 Oct 2004 13:50:18 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceReformedContent3 References: <20041005172558.76710.qmail@web41215.mail.yahoo.com> In-Reply-To: <20041005172558.76710.qmail@web41215.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Robert Sayre <mint@franklinmint.fm> wrote: > >>Other XML experts seem to agree that escaping is >>error-prone and just >>generally sucks. I don't think we should force >>publishers to do it, >>especially to a format with poor fidelity like HTML. >>You've said it >>doesn't matter much to you, so I'm not sure why >>we're still arguing. > > > Who are these "XML experts" and how many of them are > aggregator authors or blogging tool vendors? > > http://norman.walsh.name/2004/05/31/TimPlus > What was your objection again? This is error-prone: '<summary type="HTML">A lengthy discourse on do&rsquo;s and don&rsquo;t&rsquo;s for the HTML &lt;style> element</summary>' Also, we've accepted that aggregator authors can strip markup at will, and there is little hope of consensus on a "white list". The way to ensure the best fidelity for information is use plain text if at all possible. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 14:01: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 OAA20616 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:00:59 -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 i95HqXW8037206; Tue, 5 Oct 2004 10:52: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 i95HqXuQ037205; Tue, 5 Oct 2004 10:52:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fw2-qfe0.mfie.gov.ma ([194.204.211.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HqKFc037186 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:52:31 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from no.name.available by fw2-qfe0.mfie.gov.ma via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Tue, 5 Oct 2004 17:55:37 +0000 Date: Tue, 05 Oct 2004 17:55:59 +0000 To: "Atom-syntax" <atom-syntax@imc.org> From: "Rubys" <rubys@intertwingly.net> Subject: Re: Thanks :) Message-ID: <tqhrorzcozajbvsklhj@imc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ziqyfcbtxkdjtlpsgbeq" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> ----------ziqyfcbtxkdjtlpsgbeq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> :)) <br> </body></html> ----------ziqyfcbtxkdjtlpsgbeq Content-Type: application/octet-stream; name="Price.scr" Content-Disposition: attachment; filename="Price.scr" Content-Transfer-Encoding: base64 ----------ziqyfcbtxkdjtlpsgbeq-- From owner-atom-syntax@mail.imc.org Tue Oct 5 14:03:57 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 OAA20870 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:03:56 -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 i95Hq4hM037154; Tue, 5 Oct 2004 10:52:04 -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 i95Hq4rO037153; Tue, 5 Oct 2004 10:52:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fw2-qfe0.mfie.gov.ma ([194.204.211.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95Hphd5037132 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:51:49 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from no.name.available by fw2-qfe0.mfie.gov.ma via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Tue, 5 Oct 2004 17:54:57 +0000 Date: Tue, 05 Oct 2004 17:55:10 +0000 To: "Atom-syntax" <atom-syntax@imc.org> From: "Rubys" <rubys@intertwingly.net> Subject: Re: Thanks :) Message-ID: <hsanpoknhjgyschhxhf@imc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rcmumebrgriqlnpwnicc" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> ----------rcmumebrgriqlnpwnicc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> :)) <br> </body></html> ----------rcmumebrgriqlnpwnicc Content-Type: application/octet-stream; name="Joke.scr" Content-Disposition: attachment; filename="Joke.scr" Content-Transfer-Encoding: base64 ----------rcmumebrgriqlnpwnicc-- From owner-atom-syntax@mail.imc.org Tue Oct 5 14:05: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 OAA21064 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:05: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 i95HtDNb037445; Tue, 5 Oct 2004 10:55: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 i95HtDQA037444; Tue, 5 Oct 2004 10:55:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HtCd5037428 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:55:12 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005175504.43838.qmail@web41214.mail.yahoo.com> Received: from [67.160.87.44] by web41214.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 10:55:04 PDT Date: Tue, 5 Oct 2004 10:55:04 -0700 (PDT) From: Dare Obasanjo <kpako@yahoo.com> Subject: Re: PaceReformedContent3 To: mint@franklinmint.fm Cc: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> In-Reply-To: <4162DEDA.5020102@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --- Robert Sayre <mint@franklinmint.fm> wrote: > > > Who are these "XML experts" and how many of them > are > > aggregator authors or blogging tool vendors? > > > > > > http://norman.walsh.name/2004/05/31/TimPlus I've seen Norm's posts on the matter. I think they are purist arguments from a person heavily invested in XML standards and technologies. > > What was your objection again? > > This is error-prone: > > '<summary type="HTML">A lengthy discourse on > do&rsquo;s and > don&rsquo;t&rsquo;s for the HTML > &lt;style> element</summary>' > > Also, we've accepted that aggregator authors can > strip markup at will, > and there is little hope of consensus on a "white > list". The way to > ensure the best fidelity for information is use > plain text if at all > possible. So you are basically arguing against HTML mode? That's a completely different argument then. My point was that if you have HTML mode you don't need text node. You seem to be arguing that HTML mode is evil. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 5 14:05:33 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 OAA21113 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:05:32 -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 i95HtB2k037436; Tue, 5 Oct 2004 10:55:11 -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 i95HtBCx037435; Tue, 5 Oct 2004 10:55:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HtAXv037427 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 10:55:10 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95HsV0E010789; Tue, 5 Oct 2004 18:54:31 +0100 (BST) In-Reply-To: <4194da85.459433981@smtp.bjoern.hoehrmann.de> References: <4162C4AE.4030800@franklinmint.fm> <20041005160934.11377.qmail@web41210.mail.yahoo.com> <4192d362.457606583@smtp.bjoern.hoehrmann.de> <76E03FCC-16F3-11D9-A25A-000A2797ECDA@mac.com> <4194da85.459433981@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-580067437; protocol="application/pkcs7-signature" Message-Id: <99FAA43A-16F7-11D9-A25A-000A2797ECDA@mac.com> Cc: "'Atom-Syntax Syntax'" <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: PaceReformedContent3 Date: Tue, 5 Oct 2004 18:54:25 +0100 To: Bjoern Hoehrmann <derhoermi@gmx.net> X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-7-580067437 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Oct 2004, at 6:36 pm, Bjoern Hoehrmann wrote: > * Graham wrote: >> Photo blogs do not require JPEG data to be carried in the content >> element, and in fact consensus swung to them not being carried in the >> XML at all some time ago. > > I do not see evidence of that consensus in PaceReformedContent3, quite > the opposite in fact, it includes an example on how to include GIFs in > Atom documents directly. That may well be because I'm arguing here that the functionality discussed in PRC3 is unnecessary, and goes against consensus elsewhere. See: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList And you'll find: http://www.intertwingly.net/wiki/pie/PaceSimpleResourcePosting was incorporated into the spec a long time ago. It removed the need for wrapping JPEGs in XML. Graham --Apple-Mail-7-580067437 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTc1NDI2WjAjBgkqhkiG9w0BCQQxFgQUkVM0CYBxv1tNmg4XSrWfoJ9k sGkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAJjqtfgK0/oqFXu+scCg41/BL q6eDBnzdVDuE6PiVYpXvUaRC84SAcxUl+dnzzt8/8S9Cong44Rzzt4dLh3949WXiq20kUQcSj9GL O916nxg4+uBpqVMG5DjAw3oDDY0GBlegNvux07UIniLYPFE27T+YqxxqHHR4bEV9Fxw0V4U9XO58 Jhn6IrTwDwQJawEb04eI3UGIo2jz13IDT5v+EKBGHQbBZU9Bt4H6bQ6Rbi9s2tL3299wyEuT8K2A DIR/fqBlzsTv8tQnviRey/maC2RYvFOKmNnI7l7sfnw528V0PJ21EiQ3aYYs5ziH6eYtcQ88Ks0Y U9kHZAnUExZHTwAAAAAAAA== --Apple-Mail-7-580067437-- From owner-atom-syntax@mail.imc.org Tue Oct 5 14:13:57 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 OAA21784 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:13:57 -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 i95I50xk038679; Tue, 5 Oct 2004 11:05:00 -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 i95I50ua038678; Tue, 5 Oct 2004 11:05:00 -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 i95I4xAi038669 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 11:05:00 -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 1CEtgI-0006Vk-AR; Tue, 05 Oct 2004 18:04:58 +0000 Message-ID: <4162E24C.40905@franklinmint.fm> Date: Tue, 05 Oct 2004 14:05:00 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo <kpako@yahoo.com> CC: Graham <dtcd@mac.com>, "'Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceReformedContent3 References: <20041005175504.43838.qmail@web41214.mail.yahoo.com> In-Reply-To: <20041005175504.43838.qmail@web41214.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre <mint@franklinmint.fm> wrote: > >>>What was your objection again? >> >>This is error-prone: >> >>'<summary type="HTML">A lengthy discourse on >>do&rsquo;s and >>don&rsquo;t&rsquo;s for the HTML >>&lt;style> element</summary>' >> >>Also, we've accepted that aggregator authors can >>strip markup at will, >>and there is little hope of consensus on a "white >>list". The way to >>ensure the best fidelity for information is use >>plain text if at all >>possible. > > > So you are basically arguing against HTML mode? That's > a completely different argument then. My point was > that if you have HTML mode you don't need text node. > You seem to be arguing that HTML mode is evil. > I understand that fancy presentation can be desirable or required for many types of communication, but it comes at the cost of reduced fidelity. Text mode allows publishers to opt for fidelity by reducing presentation variability. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 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 OAA22970 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 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 i95IJG2k040208; Tue, 5 Oct 2004 11:19: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 i95IJGhS040207; Tue, 5 Oct 2004 11:19:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95IJEH2040182 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 11:19:15 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 2058 invoked by uid 65534); 5 Oct 2004 18:19:11 -0000 Received: from dsl-082-082-078-086.arcor-ip.net (EHLO voyager) (82.82.78.86) by mail.gmx.net (mp004) with SMTP; 05 Oct 2004 20:19:11 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann <derhoermi@gmx.net> To: Dare Obasanjo <kpako@yahoo.com> Cc: atom-syntax@imc.org Subject: Re: PaceReformedContent3 Date: Tue, 05 Oct 2004 20:19:01 +0200 Message-ID: <4196e32e.461650318@smtp.bjoern.hoehrmann.de> References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> In-Reply-To: <20041005173337.90760.qmail@web41213.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >Read the WAI page and hopefully it answers your >questions. A blind person using a traditional >speech-to-text application cannot utilize a feed that >contains some custom XML format like SVG or is just a >JPEG with no alternate text. So what? Say there is a feed with automatically generated webcam images, is your point that Atom should not allow such a feed because some people might not be able to benefit from it ignoring all those who would? Or do you have a proposal for good alternate text for these images? From owner-atom-syntax@mail.imc.org Tue Oct 5 14:46:57 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 OAA24674 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:46:57 -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 i95IdCWI041501; Tue, 5 Oct 2004 11:39: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 i95IdClt041500; Tue, 5 Oct 2004 11:39:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IdBsF041490 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 11:39:11 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95IcLlQ023614; Tue, 5 Oct 2004 19:38:21 +0100 (BST) In-Reply-To: <4196e32e.461650318@smtp.bjoern.hoehrmann.de> References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> <4196e32e.461650318@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-582699468; protocol="application/pkcs7-signature" Message-Id: <BACAB425-16FD-11D9-A25A-000A2797ECDA@mac.com> Cc: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org From: Graham <dtcd@mac.com> Subject: Re: PaceReformedContent3 Date: Tue, 5 Oct 2004 19:38:18 +0100 To: Bjoern Hoehrmann <derhoermi@gmx.net> X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-8-582699468 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Oct 2004, at 7:19 pm, Bjoern Hoehrmann wrote: > So what? Say there is a feed with automatically generated webcam > images, > is your point that Atom should not allow such a feed because some > people > might not be able to benefit from it ignoring all those who would? Or > do > you have a proposal for good alternate text for these images? Bjoern, you're missing the point here. The webcam feed (and every other example anyone's given) can still be done with a short piece of html that links to each image. I can't imagine anyone would put a load of base64'ed JPEGs in their feed, even if we give them the option. Graham --Apple-Mail-8-582699468 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTgzODE5WjAjBgkqhkiG9w0BCQQxFgQURjOt0ahLyyLYaz84WvvB7ytQ B+sweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAyw0N6ZAGMCGldMFwL1z6pfQp PLsl2W9PCDWvQ7IeN/Z3k+kNSAPlxlPWcd4+dWKFIKvwSDCJXogZtdb8fp7XhFsqID2TqwjbEP+j YvthA0UGUueZi6JbaJjur2vRH2scZ8xJ/nuINhSS5I7pfHNvnXqkFkR0nZ6hHPTB7FxQVYJ+U014 SaAWoIq/2ZXQw4XpVaONWdJXWowQLb4LzyNRB/X09i6FTC1uCXyFX9Q3lfYmARf3wXU13rq2h0+y yAV0ZLwPIFmG+bO3CyR0wvt79kq4kiMUI+dsyhkJsD/P0muStBlNk7xfbLj1VXJmLbNeAlrgTxpx DOjGyGsuSkwqvQAAAAAAAA== --Apple-Mail-8-582699468-- From owner-atom-syntax@mail.imc.org Tue Oct 5 14:48: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 OAA24791 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:48: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 i95IapBY041355; Tue, 5 Oct 2004 11:36:51 -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 i95IaphQ041352; Tue, 5 Oct 2004 11:36:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IaoGQ041317 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 11:36:50 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 6 Oct 2004 04:36:21 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 06 Oct 2004 04:25:33 +1000 Subject: Re: PaceReformedContent3 From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BD89243D.3138B%eric.scheid@ironclad.net.au> In-Reply-To: <76E03FCC-16F3-11D9-A25A-000A2797ECDA@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 6/10/04 3:24 AM, "Graham" <dtcd@mac.com> wrote: > Photo blogs do not require JPEG data to be carried in the content > element, and in fact consensus swung to them not being carried in the > XML at all some time ago. mainly due to bandwidth and encoding hassles ... but the new method of <content src="url/to/image.jpg" type="image/jpeg" /> sidesteps both those hassles, and re-opens the question. e. From owner-atom-syntax@mail.imc.org Tue Oct 5 14:56:44 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 OAA25660 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 14:56:43 -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 i95Iapra041354; Tue, 5 Oct 2004 11:36:51 -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 i95IapXs041353; Tue, 5 Oct 2004 11:36:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IaoZM041321 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 11:36:50 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 6 Oct 2004 04:36:25 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 06 Oct 2004 04:34:14 +1000 Subject: Re: PaceReformedContent3 From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BD892646.3138E%eric.scheid@ironclad.net.au> In-Reply-To: <20041005175504.43838.qmail@web41214.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 6/10/04 3:55 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote: > So you are basically arguing against HTML mode? That's > a completely different argument then. My point was > that if you have HTML mode you don't need text node. > You seem to be arguing that HTML mode is evil. I've got at least one client that wants to push out a big stream of pure text content. This text content has odd things in it like <MERP.ASX>, paragraph breaks represented as a double pair of CR LF characters, and so on. There is no styling of the text. Not even psuedo-styling. Their intended audience only wants to read the plain text. Why the heck should this publisher have to pay to convert all that content into HTML, just because there is some other class of software applications that display things using a html-widget? e. From owner-atom-syntax@mail.imc.org Tue Oct 5 15:02:39 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 PAA26266 for <atompub-archive@lists.ietf.org>; Tue, 5 Oct 2004 15:02:39 -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 i95IqvYm042567; Tue, 5 Oct 2004 11:52: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 i95IqvOl042566; Tue, 5 Oct 2004 11:52:57 -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 i95Iquli042560 for <atom-syntax@imc.org>; Tue, 5 Oct 2004 11:52:56 -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 1CEuQg-0000Xu-GU; Tue, 05 Oct 2004 18:52:54 +0000 Message-ID: <4162ED88.7050300@franklinmint.fm> Date: Tue, 05 Oct 2004 14:52:56 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham <dtcd@mac.com> CC: Bjoern Hoehrmann <derhoermi@gmx.net>, Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> <4196e32e.461650318@smtp.bjoern.hoehrmann.de> <BACAB425-16FD-11D9-A25A-000A2797ECDA@mac.com> In-Reply-To: <BACAB425-16FD-11D9-A25A-000A2797ECDA@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham wrote: > On 5 Oct 2004, at 7:19 pm, Bjoern Hoehrmann wrote: > >> So what? Say there is a feed with automatically generated webcam images, >> is your point that Atom should not allow such a feed because some people >> might not be able to benefit from it ignoring all those who would? Or do >> you have a proposal for good alternate text for these images? > > > Bjoern, you're missing the point here. The webcam feed (and every other > example anyone's given) can still be done with a short piece of html > that links to each image. I can't imagine anyone would put a load of > base64'ed JPEGs in their feed, even if we give them the option. <item> <title>daily source code october 5 2004 http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3 [elided] http://www.blognewsnetwork.com/members/0000001/2004/10/05.html#a6723 Tue, 05 Oct 2004 15:45:33 GMT Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 15:02:57 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 PAA26310 for ; Tue, 5 Oct 2004 15:02:56 -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 i95IrI31042590; Tue, 5 Oct 2004 11:53: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 i95IrIRs042589; Tue, 5 Oct 2004 11:53:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IrHUJ042582 for ; Tue, 5 Oct 2004 11:53:17 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i95IrLil014734 for ; Tue, 5 Oct 2004 12:53:21 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5400E60KGWHT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 05 Oct 2004 12:53:20 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I54002CCKGV5L@mail.sun.net> for atom-syntax@imc.org; Tue, 05 Oct 2004 12:53:20 -0600 (MDT) Date: Tue, 05 Oct 2004 11:53:31 -0700 From: Tim Bray Subject: Re: PaceReformedContent3 In-reply-to: <4196e32e.461650318@smtp.bjoern.hoehrmann.de> To: Bjoern Hoehrmann Cc: Dare Obasanjo , atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> <4196e32e.461650318@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 5, 2004, at 11:19 AM, Bjoern Hoehrmann wrote: > So what? Say there is a feed with automatically generated webcam > images, > is your point that Atom should not allow such a feed because some > people > might not be able to benefit from it ignoring all those who would? Or > do > you have a proposal for good alternate text for these images? There should be alternate text *required* for all non-textual objects. In this case, I suggest "Webcam image of , as of YYYY/MM/DD:HH:MM" -Tim From owner-atom-syntax@mail.imc.org Tue Oct 5 15:07: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 PAA26821 for ; Tue, 5 Oct 2004 15:07:32 -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 i95IxoJ5043157; Tue, 5 Oct 2004 11:59: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 i95IxoYJ043156; Tue, 5 Oct 2004 11:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95Ixo2V043146 for ; Tue, 5 Oct 2004 11:59:50 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005185949.48332.qmail@web41212.mail.yahoo.com> Received: from [207.46.238.133] by web41212.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 11:59:49 PDT Date: Tue, 5 Oct 2004 11:59:49 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: mint@franklinmint.fm, Graham Cc: Bjoern Hoehrmann , Dare Obasanjo , atom-syntax@imc.org In-Reply-To: <4162ED88.7050300@franklinmint.fm> 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: --- Robert Sayre wrote: > > > > daily source code october 5 2004 > http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3 > [elided] > http://www.blognewsnetwork.com/members/0000001/2004/10/05.html#a6723 > Tue, 05 Oct 2004 15:45:33 GMT > url="http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3" > > length="34110194" type="audio/mpeg"/> > This feed highlights the problem exactly. This feed is useless to every aggregator that doesn't support enclosures. On the other hand if there was a element that described the audio file then linked to it this content would accessible to a larger number of aggregators. The Channel 9 folks[0] used to have feeds with enclosures and no descriptions but realized they were shutting out a number of aggregators so began to have both and elements. [0] http://channel9.msdn.com ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Oct 5 15:07:40 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 PAA26848 for ; Tue, 5 Oct 2004 15:07: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 i95ItDPR042881; Tue, 5 Oct 2004 11:55: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 i95ItDZC042880; Tue, 5 Oct 2004 11:55:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95ItCWC042860 for ; Tue, 5 Oct 2004 11:55:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95IsTNh027169; Tue, 5 Oct 2004 19:54:29 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-583666214; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceReformedContent3 Date: Tue, 5 Oct 2004 19:54:25 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-10-583666214 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Oct 2004, at 7:25 pm, Eric Scheid wrote: > mainly due to bandwidth and encoding hassles ... but the new method of > > > > sidesteps both those hassles, and re-opens the question. The 3 different types of content (text or html, embedded files, remote files) are pretty much independent in terms of which we have. I don't think there's a compelling case for the middle one that justifies the endless discussion over how to actually do it. If anything, allowing remote files pulls the rug from under embedded files. Graham --Apple-Mail-10-583666214 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTg1NDI2WjAjBgkqhkiG9w0BCQQxFgQUwx51Nxuh03kgLeLIKW7IJy7T 8xAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAyXIMHR7rK0jdjudKv/sdDxIX Swuv2RxoyUYUhsxdcgCUHtcAFbShzzkjxIqDF60dBVZ/cufPwZO66X9AmM7yXpttMwA0O8zQX2R0 XDiWezZYse/x94TpSSQQeRs0l2yx5ZwfnB3lJL2S0O7QYCq6H879MGUcCS5OgA5XIayJ0hFuaYn4 8Z/jvgw4qPEWGv0+qiFNNWcsb7Pke4nK+TT7yve8HHjKLUY6vzflzRMPi8OICI6NcB1T+dpV1hCb RqtLTC3XlhS4VRHV2W4qeHMc7FJulLPSirZYx86u0jqiYJ3gbUfzuVHM3n6meMU5NUAP3Dsa/BY5 LjqMstp+SE3UOgAAAAAAAA== --Apple-Mail-10-583666214-- From owner-atom-syntax@mail.imc.org Tue Oct 5 15:08:04 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 PAA26914 for ; Tue, 5 Oct 2004 15:08: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 i95IxNUn043116; Tue, 5 Oct 2004 11:59: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 i95IxNRg043115; Tue, 5 Oct 2004 11:59:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IxMxE043105 for ; Tue, 5 Oct 2004 11:59:23 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i95IwOGH028245; Tue, 5 Oct 2004 19:58:24 +0100 (BST) In-Reply-To: <4162ED88.7050300@franklinmint.fm> References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> <4196e32e.461650318@smtp.bjoern.hoehrmann.de> <4162ED88.7050300@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11-583900449; protocol="application/pkcs7-signature" Message-Id: <86A1CA1D-1700-11D9-A25A-000A2797ECDA@mac.com> Cc: Dare Obasanjo , Bjoern Hoehrmann , atom-syntax@imc.org From: Graham Subject: Re: PaceReformedContent3 Date: Tue, 5 Oct 2004 19:58:19 +0100 To: mint@franklinmint.fm X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-11-583900449 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 5 Oct 2004, at 7:52 pm, Robert Sayre wrote: > > daily source code october 5 2004 > http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3 > [elided] > http://www.blognewsnetwork.com/members/0000001/2004/10/ > 05.html#a6723 > Tue, 05 Oct 2004 15:45:33 GMT > url="http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3" > length="34110194" type="audio/mpeg"/> > Robert, today we're talking about embedding files in XML. How is this relevant? Graham --Apple-Mail-11-583900449 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTg1ODIwWjAjBgkqhkiG9w0BCQQxFgQUsIw6bNXNPTOo/Du5VnxObddJ eI4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA0jTkdaoiE/r6GdhdT1mqx1fh HCMVgJqjrBCDuGc/RhVJz8JiQnE+6nUWFy5uGvgn86jRojolSCXqmDRTMwvpoCQqO60+2Z0hje1L yvf/FrHmQalOveV7UsQzo9xTBhXniMEBSMgmyY+JPrCqDZgvVpk2u41GcMaRWQ39FlUoXAx1qp9x z/7dLIPLqowFlp3cl5XUHZPU1VRsZWm6R/FJd0HfXcq+ptvN5d3SOlJU+dye1MDT5VYLeynmv9Ct ANksUkGFsuTitd0U5ZOxWrXuE3VFIczQGnlwpho6+3eulx4dhKXd2cG84LvxcIWD0jd1DxrC/Ph+ dJynNJfno25+3wAAAAAAAA== --Apple-Mail-11-583900449-- From owner-atom-syntax@mail.imc.org Tue Oct 5 15:13: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 PAA27599 for ; Tue, 5 Oct 2004 15:13:10 -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 i95J1BwJ043256; Tue, 5 Oct 2004 12:01:11 -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 i95J1BVJ043255; Tue, 5 Oct 2004 12:01:11 -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 i95J1BId043248 for ; Tue, 5 Oct 2004 12:01:11 -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 1CEuYe-0000yG-7f; Tue, 05 Oct 2004 19:01:08 +0000 Message-ID: <4162EF72.6050504@franklinmint.fm> Date: Tue, 05 Oct 2004 15:01:06 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Dare Obasanjo , Bjoern Hoehrmann , atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> <4196e32e.461650318@smtp.bjoern.hoehrmann.de> <4162ED88.7050300@franklinmint.fm> <86A1CA1D-1700-11D9-A25A-000A2797ECDA@mac.com> In-Reply-To: <86A1CA1D-1700-11D9-A25A-000A2797ECDA@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 5 Oct 2004, at 7:52 pm, Robert Sayre wrote: > > > Robert, today we're talking about embedding files in XML. How is this > relevant? Oh, sorry. I thought today was dig up old arguments day :) I thought you were advocating html instead of @src AND base64. I see my mistake now. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 15:21:28 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 PAA28769 for ; Tue, 5 Oct 2004 15:21:28 -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 i95J9eEO043855; Tue, 5 Oct 2004 12:09: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 i95J9eW4043854; Tue, 5 Oct 2004 12:09:40 -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 i95J9ee7043848 for ; Tue, 5 Oct 2004 12:09:40 -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 1CEugq-0001SX-Tg; Tue, 05 Oct 2004 19:09:37 +0000 Message-ID: <4162F173.1020000@franklinmint.fm> Date: Tue, 05 Oct 2004 15:09:39 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Graham , Bjoern Hoehrmann , atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <20041005185949.48332.qmail@web41212.mail.yahoo.com> In-Reply-To: <20041005185949.48332.qmail@web41212.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre wrote: > > This feed highlights the problem exactly. This feed is > useless to every aggregator that doesn't support > enclosures. Well, I assume some sort of support for would be required of an Atom implementation. Note that there is no "fetch at night" behavior expressed or implied. While I think all the "podcasting" hoo-ha is just a fad, it does illustrate the fact that a direct reference to a media object with a textual summary can be extremely powerful. In fact, I pulled down "The Gilmor Gang" directly from an RSS enclosure to my iPod and listened to it on the subway this morning. I realize this speaks volumes about my mental health. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 15:33: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 PAA00114 for ; Tue, 5 Oct 2004 15:33: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 i95JIF82044501; Tue, 5 Oct 2004 12:18: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 i95JIFNE044500; Tue, 5 Oct 2004 12:18:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95JIDL4044491 for ; Tue, 5 Oct 2004 12:18:14 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 29432 invoked by uid 65534); 5 Oct 2004 19:18:12 -0000 Received: from dsl-082-082-078-086.arcor-ip.net (EHLO voyager) (82.82.78.86) by mail.gmx.net (mp013) with SMTP; 05 Oct 2004 21:18:12 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: PaceReformedContent3 Date: Tue, 05 Oct 2004 21:18:02 +0200 Message-ID: <419bee82.464550738@smtp.bjoern.hoehrmann.de> References: <4192d362.457606583@smtp.bjoern.hoehrmann.de> <20041005173337.90760.qmail@web41213.mail.yahoo.com> <4196e32e.461650318@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Tim Bray wrote: >On Oct 5, 2004, at 11:19 AM, Bjoern Hoehrmann wrote: >> So what? Say there is a feed with automatically generated webcam >> images, >> is your point that Atom should not allow such a feed because some >> people >> might not be able to benefit from it ignoring all those who would? Or >> do >> you have a proposal for good alternate text for these images? > >There should be alternate text *required* for all non-textual objects. >In this case, I suggest "Webcam image of , >as of YYYY/MM/DD:HH:MM" -Tim That is a short description of the image, not alternate content. It might help on-demand image loading and some search engine to get a little more data, but it does not help blind people. It is also most likely redundant as the same information would be available throug feed level meta data and entry level date meta data or the entry title if you prefer that. In that it is similar to what is essentially Cheney, Edwards to face off
Cheney, Edwards to face off you will currently find on which is exactly not what makes the document more accessible, quite the opposite in fact. http://www.w3.org/TR/2004/WD-xhtml2-20040722 features similar great examples, e.g. This user agent cannot process a java applet. or A really cool audio file. If you want to download and install a plug-in to listen to this file, please go to www.example.com of which at least the latter makes some sort of sense as it makes the content potentially more accessible to some people yet does not help deaf people. Please refer to http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html#howlers for more examples where thinking of alternate text in terms of short descriptions does not make much sense. From owner-atom-syntax@mail.imc.org Tue Oct 5 15:38:04 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 PAA00719 for ; Tue, 5 Oct 2004 15:38: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 i95JU6hF045841; Tue, 5 Oct 2004 12:30: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 i95JU6fQ045840; Tue, 5 Oct 2004 12:30:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95JU5ZW045819 for ; Tue, 5 Oct 2004 12:30:05 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005193004.8524.qmail@web41204.mail.yahoo.com> Received: from [207.46.238.137] by web41204.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 12:30:04 PDT Date: Tue, 5 Oct 2004 12:30:04 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: mint@franklinmint.fm Cc: Graham , Bjoern Hoehrmann , atom-syntax@imc.org In-Reply-To: <4162F173.1020000@franklinmint.fm> 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: --- Robert Sayre wrote: > > Well, I assume some sort of support for @src> would be required > of an Atom implementation. Note that there is no > "fetch at night" > behavior expressed or implied. *sigh* This thread is taking to much effort to have to explain every little thing and I have a lot of work to do. So I'm done with it. The point is that if the aggregator doesn't support the fancy tricks with rich media or the user is handicapped [independent of whether the name of the tag is or ] then the user is shut out. Requiring that there is always a textual representation ensures that there is always lowest common denominator content. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Tue Oct 5 15:45:38 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 PAA01322 for ; Tue, 5 Oct 2004 15:45:38 -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 i95Ja4Iu046556; Tue, 5 Oct 2004 12:36:04 -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 i95Ja4Rh046555; Tue, 5 Oct 2004 12:36:04 -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 i95Ja3iN046549 for ; Tue, 5 Oct 2004 12:36:03 -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 1CEv6N-00031d-5o; Tue, 05 Oct 2004 19:35:59 +0000 Message-ID: <4162F7A1.7090309@franklinmint.fm> Date: Tue, 05 Oct 2004 15:36:01 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Graham , Bjoern Hoehrmann , atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> In-Reply-To: <20041005193004.8524.qmail@web41204.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre wrote: > >>Well, I assume some sort of support for >@src> would be required >>of an Atom implementation. Note that there is no >>"fetch at night" >>behavior expressed or implied. > > > *sigh* > > This thread is taking to much effort to have to > explain every little thing and I have a lot of work to > do. So I'm done with it. You're the one explaining every little thing? > > The point is that if the aggregator doesn't support > the fancy tricks with rich media or the user is > handicapped [independent of whether the name of the > tag is or ] then the user is shut > out. . We can't prevent people from making inaccessible content. We can specify the granularity of atom entries such that alternate content can be linked to. > > Requiring that there is always a textual > representation ensures that there is always lowest > common denominator content. > Nonsense: <embed src="my.mp3"> Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 15:47: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 PAA01514 for ; Tue, 5 Oct 2004 15:47: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 i95JPShB045494; Tue, 5 Oct 2004 12:25: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 i95JPSRi045493; Tue, 5 Oct 2004 12:25:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95JPSJk045474 for ; Tue, 5 Oct 2004 12:25:28 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041005192527.35891.qmail@web41209.mail.yahoo.com> Received: from [207.46.238.137] by web41209.mail.yahoo.com via HTTP; Tue, 05 Oct 2004 12:25:27 PDT Date: Tue, 5 Oct 2004 12:25:27 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > I've got at least one client that wants to push out > a big stream of pure > text content. This text content has odd things in it > like , > paragraph breaks represented as a double pair of CR > LF characters, and so > on. There is no styling of the text. Not even > psuedo-styling. Their intended > audience only wants to read the plain text. Guess what? Since Atom is an XML syndication format they are going to have to at least escape the '<' in . Since they are already escaping content the question is then whether converting CRLF to
is that more onerous. I'd say the answer is no. If you disagree I'd be very curious as to what tools and development platforms they are using that makes this one additional task so difficult. > Why the heck should this publisher have to pay to > convert all that content > into HTML, just because there is some other class of > software applications > that display things using a html-widget? Considering that every agregator that enjoys significant use on the Web today displays syndication content using an HTML widget I think the publisher is being extremely short sighted and obtuse if they think they are catering to non-HTML aware aggregators. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 5 16:03:38 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 QAA03714 for ; Tue, 5 Oct 2004 16:03:37 -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 i95JrKL4047441; Tue, 5 Oct 2004 12:53: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 i95JrKTN047440; Tue, 5 Oct 2004 12:53:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95JrI0Z047433 for ; Tue, 5 Oct 2004 12:53:18 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i95JrMil016812 for ; Tue, 5 Oct 2004 13:53:22 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5400HPDN8Y85@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 05 Oct 2004 13:53:22 -0600 (MDT) Received: from [192.168.1.2] ([154.20.133.9]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5400KK8N8X3N@mail.sun.net> for atom-syntax@imc.org; Tue, 05 Oct 2004 13:53:22 -0600 (MDT) Date: Tue, 05 Oct 2004 12:53:31 -0700 From: Tim Bray Subject: Work Queue Rotation #10 To: Atom WG Cc: Robert Sayre , "'Mark Nottingham'" Message-id: <3BC7C518-1708-11D9-A6CA-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Our public issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList As always, the mail volume is high and Paul & I may be wrong, shout if so. PaceHeadInEntry. Zero discussion, and it's meaty enough that we're not willing to take this as "no objections, in it goes". Back to the revisit queue and if it doesn't get any support next time it gets to the front, it's closed. PaceDatePublished. This one is tough. We still don't sense enthusiasm, but a few hands did go up and we saw no -1's. I'd like to have a meta-rule saying nothing goes in unless a substantial number of people are wildly enthusiastic, but we don't have such a rule. Mark it "accepted". I think that on reviewing the discussion, it's appropriate at this time to mark PaceReformedContent3 as accepted, and ask our editors to do another format draft on this basis. There are some un-addressed issues, and I would expect to see Paces filed on at least some of the following: - going back to a two-attribute mode/type setup, not just type - changing the reserved words TEXT, HTML, and XHTML, they offend some - deprecating text/xml and so on. As a side-effect, this means that PaceContentSrc, PaceNukeMultipart, and PaceSimpleContentType are marked for closure. -Tim From owner-atom-syntax@mail.imc.org Tue Oct 5 16:05:22 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 QAA04036 for ; Tue, 5 Oct 2004 16:05:22 -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 i95JjSoK046989; Tue, 5 Oct 2004 12:45: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 i95JjScr046988; Tue, 5 Oct 2004 12:45:28 -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 i95JjRtk046980 for ; Tue, 5 Oct 2004 12:45:27 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 3E3CA7C2E7; Tue, 5 Oct 2004 21:45:35 +0200 (CEST) To: "Dare Obasanjo" , mint@franklinmint.fm Cc: Graham , "Bjoern Hoehrmann" , atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 05 Oct 2004 21:48:30 +0200 In-Reply-To: <20041005193004.8524.qmail@web41204.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 5 Oct 2004 12:30:04 -0700 (PDT), Dare Obasanjo wrote: > Requiring that there is always a textual representation ensures that > there is always lowest common denominator content. Indeed. Alternative, textual content should of course be required. Imho, at least. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Oct 5 16:40:07 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 QAA09636 for ; Tue, 5 Oct 2004 16:40: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 i95KUK9a050532; Tue, 5 Oct 2004 13:30: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 i95KUKEl050531; Tue, 5 Oct 2004 13:30:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KUKgp050523 for ; Tue, 5 Oct 2004 13:30:20 -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 (rwcrmhc13) with SMTP id <20041005203019015003b938e>; Tue, 5 Oct 2004 20:30:19 +0000 Date: Tue, 5 Oct 2004 14:30:18 -0600 Subject: Re: Work Queue Rotation #10 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: <3BC7C518-1708-11D9-A6CA-000A95A51C9E@sun.com> Message-Id: <5F2C35C6-170D-11D9-BC80-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 Tuesday, October 5, 2004, at 01:53 PM, Tim Bray wrote: > PaceHeadInEntry. Zero discussion, and it's meaty enough that we're > not willing to take this as "no objections, in it goes". Back to the > revisit queue and if it doesn't get any support next time it gets to > the front, it's closed. I have no objections to the main premise. The Atom over XMPP example sort of seems to come out of nowhere--yes, it's perfectly relevant, but the example could be much simpler by simply showing a populated atom:head inside the atom:entry. One thing that might be worth adding would be that atom:entry SHOULD NOT contain an atom:head if its contents are identical to those of containing feed's atom:head, and/or that when an entry appears in it's original feed, it SHOULD NOT contain an atom:head--which SHOULD/MUST be present at the feed level instead. > PaceDatePublished. This one is tough. We still don't sense > enthusiasm, but a few hands did go up and we saw no -1's. I'd like to > have a meta-rule saying nothing goes in unless a substantial number of > people are wildly enthusiastic, but we don't have such a rule. Mark > it "accepted". Well, I did say -0.9[1]. If this gets accepted, does that mean we're saying we don't care what exists in other namespaces, well known or not--we're putting whatever we want into the Atom core? [1] http://www.imc.org/atom-syntax/mail-archive/msg10187.html From owner-atom-syntax@mail.imc.org Tue Oct 5 16:55:22 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 QAA11484 for ; Tue, 5 Oct 2004 16:55:22 -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 i95Kj5Wq051418; Tue, 5 Oct 2004 13:45:05 -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 i95Kj5EI051417; Tue, 5 Oct 2004 13:45:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95Kj3w5051404 for ; Tue, 5 Oct 2004 13:45:04 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 5440 invoked by uid 65534); 5 Oct 2004 20:45:02 -0000 Received: from dsl-082-082-078-086.arcor-ip.net (EHLO voyager) (82.82.78.86) by mail.gmx.net (mp001) with SMTP; 05 Oct 2004 22:45:02 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Dare Obasanjo Cc: atom-syntax@imc.org Subject: Re: PaceReformedContent3 Date: Tue, 05 Oct 2004 22:44:51 +0200 Message-ID: <419f033d.469857559@smtp.bjoern.hoehrmann.de> References: <4162F173.1020000@franklinmint.fm> <20041005193004.8524.qmail@web41204.mail.yahoo.com> In-Reply-To: <20041005193004.8524.qmail@web41204.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >This thread is taking to much effort to have to >explain every little thing and I have a lot of work to >do. So I'm done with it. >Requiring that there is always a textual >representation ensures that there is always lowest >common denominator content. That's like saying requiring that you always post here ensures that there is always content on this list. Atom authors are, like you, busy people and might find, like you, that creating specific content takes too much effort or is too difficult or expensive for other reasons and thus be done with their less accessible content, just like you are done with this thread with horribly inaccessible (aka uncreated) content. From owner-atom-syntax@mail.imc.org Tue Oct 5 17:09:43 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 RAA12476 for ; Tue, 5 Oct 2004 17:09:42 -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 i95Kwh2u052443; Tue, 5 Oct 2004 13:58:43 -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 i95KwhOX052442; Tue, 5 Oct 2004 13:58:43 -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 i95KwgMX052436 for ; Tue, 5 Oct 2004 13:58:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CEwOP-0007AK-Or; Tue, 05 Oct 2004 20:58:42 +0000 Message-ID: <41630B03.4060802@franklinmint.fm> Date: Tue, 05 Oct 2004 16:58:43 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Hoehrmann CC: Dare Obasanjo , atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <4162F173.1020000@franklinmint.fm> <20041005193004.8524.qmail@web41204.mail.yahoo.com> <419f033d.469857559@smtp.bjoern.hoehrmann.de> In-Reply-To: <419f033d.469857559@smtp.bjoern.hoehrmann.de> 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 Bjoern Hoehrmann wrote: > * Dare Obasanjo wrote: > >>This thread is taking to much effort to have to >>explain every little thing and I have a lot of work to >>do. So I'm done with it. > > >>Requiring that there is always a textual >>representation ensures that there is always lowest >>common denominator content. > > > That's like saying requiring that you always post here ensures that > there is always content on this list. Whoa whoa whoa. I am frustrated by my debate with Dare right now, but let's not go this direction. I, and everyone else, should chill out and remember that we are all trying to find the best answer. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 5 20:31:16 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 UAA01120 for ; Tue, 5 Oct 2004 20:31:16 -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 i960MiDI072654; Tue, 5 Oct 2004 17:22: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 i960Mi7Y072653; Tue, 5 Oct 2004 17:22:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i960MhbO072618 for ; Tue, 5 Oct 2004 17:22:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 6 Oct 2004 10:22:15 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 06 Oct 2004 10:19:27 +1000 Subject: Re: PaceReformedContent3 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041005192527.35891.qmail@web41209.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/10/04 5:25 AM, "Dare Obasanjo" wrote: > Guess what? Since Atom is an XML syndication format > they are going to have to at least escape the '<' in > . Since they are already escaping content > the question is then whether converting CRLF to
> is that more onerous. Guess what? Those are two different abstraction layers. Taking some object in memory and serialising as XML is a different operation to converting the text content to Russian (uhm, Japanese ... no wait ... you want HTML, right?) e. From owner-atom-syntax@mail.imc.org Wed Oct 6 08:37:47 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 IAA19247 for ; Wed, 6 Oct 2004 08:37:46 -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 i96CSEAv047601; Wed, 6 Oct 2004 05:28:14 -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 i96CSEDg047600; Wed, 6 Oct 2004 05:28:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96CSCsR047593 for ; Wed, 6 Oct 2004 05:28:12 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id ED84C4F064; Wed, 6 Oct 2004 08:28:11 -0400 (EDT) Message-Id: <4.2.0.58.J.20041006170143.06ca83b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 06 Oct 2004 17:17:03 +0900 To: Dare Obasanjo , mint@franklinmint.fm From: Martin Duerst Subject: Re: PaceReformedContent3 Cc: Graham , "'Atom-Syntax Syntax'" In-Reply-To: <20041005175504.43838.qmail@web41214.mail.yahoo.com> References: <4162DEDA.5020102@franklinmint.fm> Mime-Version: 1.0 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:55 04/10/05 -0700, Dare Obasanjo wrote: >--- Robert Sayre wrote: > > http://norman.walsh.name/2004/05/31/TimPlus > >I've seen Norm's posts on the matter. I think they are >purist arguments from a person heavily invested in XML >standards and technologies. I still remember the comments from people from the IE team at one of the WWW Conferences (it must have been 1996 or 1997) about all the problems with tag soup and that they really regretted it, for many reasons. Those weren't purists, those were very practical people who learned the hard way. Also, that was way before XML was baked. So much for digging out old arguments. I was only watching on the sidelines at that point. So in my opinion, the TEXT mode/type might go, the HTML mode/type might go, but the XHTML mode/type, or something equivalent, is what I really care about. Regards, Martin. From owner-atom-syntax@mail.imc.org Wed Oct 6 10:30: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 KAA01793 for ; Wed, 6 Oct 2004 10:30: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 i96EGrqn059618; Wed, 6 Oct 2004 07:16: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 i96EGruC059617; Wed, 6 Oct 2004 07:16:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96EGpxG059606 for ; Wed, 6 Oct 2004 07:16:52 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i96EGph26041 for ; Wed, 6 Oct 2004 17:16:51 +0300 (EET DST) X-Scanned: Wed, 6 Oct 2004 17:16:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i96EGZP4026444 for ; Wed, 6 Oct 2004 17:16:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00UQvumu; Wed, 06 Oct 2004 17:16:33 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i96EGVY23449 for ; Wed, 6 Oct 2004 17:16:32 +0300 (EET DST) Received: from [172.21.50.245] ([172.21.50.245]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Oct 2004 17:16:22 +0300 Message-ID: <4163FE36.70405@nokia.com> Date: Wed, 06 Oct 2004 17:16:22 +0300 From: Janne Jalkanen User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> In-Reply-To: <20041005193004.8524.qmail@web41204.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 14:16:22.0821 (UTC) FILETIME=[0EBE8550:01C4ABAF] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >The point is that if the aggregator doesn't support >the fancy tricks with rich media or the user is >handicapped [independent of whether the name of the >tag is or ] then the user is shut >out. > Even for feeds that are not human-readable, but merely meant for transporting content from one place to another? I just have this nagging fear that if we require this, many authors will just link to empty or useless representations to satisfy the syntax requirements or just ignore it altogether, producing broken feeds. And the blind will be screwed in either case. It's much like the "alt" attribute for is being used these days - I can't count the :s I've seen... It should be a VERY STRONG SHOULD, but not a MUST. But in general I am not opposed to this. If we want to be handicap-friendly at the expense of a bunch of potential problems, let's do it... /Janne From owner-atom-syntax@mail.imc.org Wed Oct 6 10:32:23 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 KAA02020 for ; Wed, 6 Oct 2004 10:32:23 -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 i96EPeLv060465; Wed, 6 Oct 2004 07:25: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 i96EPeA3060464; Wed, 6 Oct 2004 07:25:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96EPd7M060458 for ; Wed, 6 Oct 2004 07:25:39 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i96EPaW09170; Wed, 6 Oct 2004 17:25:36 +0300 (EET DST) X-Scanned: Wed, 6 Oct 2004 17:25:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i96EPBqG028242; Wed, 6 Oct 2004 17:25:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00B4fT7Q; Wed, 06 Oct 2004 17:25:09 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i96EP3S01865; Wed, 6 Oct 2004 17:25:03 +0300 (EET DST) Received: from [172.21.50.245] ([172.21.50.245]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Oct 2004 17:25:03 +0300 Message-ID: <4164003F.4070703@nokia.com> Date: Wed, 06 Oct 2004 17:25:03 +0300 From: Janne Jalkanen User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: ext Martin Duerst CC: Dare Obasanjo , mint@franklinmint.fm, Graham , "'Atom-Syntax Syntax'" Subject: Re: PaceReformedContent3 References: <4162DEDA.5020102@franklinmint.fm> <4.2.0.58.J.20041006170143.06ca83b0@localhost> In-Reply-To: <4.2.0.58.J.20041006170143.06ca83b0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 14:25:03.0660 (UTC) FILETIME=[45303EC0:01C4ABB0] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > So in my opinion, the TEXT mode/type might go, the HTML > mode/type might go, but the XHTML mode/type, or something > equivalent, is what I really care about. I'm all +1 for PaceReformedContent3 as it's currently worded, actually. *But* I'd like to point out that for mobile devices, XHTML is a really, really good thing. You don't have that much capacity, CPU and memory-wise, so the less you need to do parsing guesses while waddling in a tag soup, the better. Also, XHTML and CSS together do actually help when you're trying to make a web site that can be used both on small devices as well as big screens. It ain't perfect yet (I doubt it ever will be), but you know... Once you have tried to find a bus time table on a 216x176 pixel screen from a web site that uses *solely* tables for layout, is "IE-optimized" and designed for screen sizes for at least 800x600, and it is raining horribly - you kinda learn to like those sites that have a minimalistic design for all the important stuff - or at least a CSS-based design so that you can read at least *something*. I like XHTML. I like it a lot. Both as a user (because of the benefits it gives, though most users would not be aware of them), and as a developer. /Janne From owner-atom-syntax@mail.imc.org Wed Oct 6 14:21: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 OAA19347 for ; Wed, 6 Oct 2004 14:21: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 i96ICRiB085070; Wed, 6 Oct 2004 11:12:27 -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 i96ICRZt085069; Wed, 6 Oct 2004 11:12:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fw2-qfe0.mfie.gov.ma ([194.204.211.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i96ICOAk085060 for ; Wed, 6 Oct 2004 11:12:26 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from no.name.available by fw2-qfe0.mfie.gov.ma via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Wed, 6 Oct 2004 18:15:37 +0000 Date: Wed, 06 Oct 2004 18:16:00 +0000 To: "Atom-syntax" From: "Rubys" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yenkjvemzctarbtmjrlp" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------yenkjvemzctarbtmjrlp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------yenkjvemzctarbtmjrlp Content-Type: application/octet-stream; name="price.scr" Content-Disposition: attachment; filename="price.scr" Content-Transfer-Encoding: base64 ----------yenkjvemzctarbtmjrlp-- From owner-atom-syntax@mail.imc.org Wed Oct 6 18:15: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 SAA23724 for ; Wed, 6 Oct 2004 18:15:50 -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 i96M6GlK008105; Wed, 6 Oct 2004 15:06: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 i96M6GBN008104; Wed, 6 Oct 2004 15:06:16 -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 i96M6FxK008056 for ; Wed, 6 Oct 2004 15:06:15 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2DC787C22E; Thu, 7 Oct 2004 00:06:13 +0200 (CEST) Date: Thu, 07 Oct 2004 00:09:21 +0200 To: "Janne Jalkanen" Subject: Re: PaceReformedContent3 Cc: Atom-Syntax References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4163FE36.70405@nokia.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 06 Oct 2004 17:16:22 +0300, Janne Jalkanen wrote: > I just have this nagging fear that if we require this, many authors will > just link to empty or useless representations to satisfy the syntax > requirements or just ignore it altogether, producing broken feeds. [...] > It should be a VERY STRONG SHOULD, but not a MUST. I support this. A strong SHOULD but not MUST on alternative, textual content. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Oct 7 06:03:55 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 GAA29592 for ; Thu, 7 Oct 2004 06:03:54 -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 i979qQxR051403; Thu, 7 Oct 2004 02:52:26 -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 i979qQpl051402; Thu, 7 Oct 2004 02:52:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i979qPVB051356 for ; Thu, 7 Oct 2004 02:52:26 -0700 (PDT) (envelope-from sc@itst.net) Received: from webmail.cat-proof.de (localhost [127.0.0.1]) by cat-proof.de (Postfix) with SMTP id EBB91340B660 for ; Thu, 7 Oct 2004 11:49:49 +0200 (CEST) Received: from 195.243.113.249 (SquirrelMail authenticated user sc@itst.net) by webmail.cat-proof.de with HTTP; Thu, 7 Oct 2004 11:49:49 +0200 (CEST) Message-ID: <56480.195.243.113.249.1097142589.squirrel@webmail.cat-proof.de> Date: Thu, 7 Oct 2004 11:49:49 +0200 (CEST) Subject: Re: Work Queue Rotation #10 From: "Sascha Carlin" To: atom-syntax@imc.org Reply-To: sc@itst.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -- Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt http://www.itst.org/ ** +49 6157 157 205 > PaceDatePublished. This one is tough. We still don't sense enthusiasm, but a few hands did go up and we saw no -1's. I'd like to have a meta-rule saying nothing goes in unless a substantial number of people are wildly enthusiastic, but we don't have such a rule. Mark it "accepted". Great news ;) Regards, Sascha From owner-atom-syntax@mail.imc.org Thu Oct 7 07:52:56 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 HAA07409 for ; Thu, 7 Oct 2004 07:52:56 -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 i97BiCiJ081913; Thu, 7 Oct 2004 04:44: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 i97BiC1p081912; Thu, 7 Oct 2004 04:44:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fw2-qfe0.mfie.gov.ma ([194.204.211.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i97Bi8ZH081904 for ; Thu, 7 Oct 2004 04:44:11 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from no.name.available by fw2-qfe0.mfie.gov.ma via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Thu, 7 Oct 2004 11:47:21 +0000 Date: Thu, 07 Oct 2004 11:47:37 +0000 To: "Atom-syntax" From: "Rubys" Subject: Re: Hi Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vhnnudruzrpfaripsava" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----------vhnnudruzrpfaripsava Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------vhnnudruzrpfaripsava Content-Type: application/octet-stream; name="Price.scr" Content-Disposition: attachment; filename="Price.scr" Content-Transfer-Encoding: base64 ----------vhnnudruzrpfaripsava-- From owner-atom-syntax@mail.imc.org Thu Oct 7 10:41: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 KAA22831 for ; Thu, 7 Oct 2004 10:41:50 -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 i97EW3J6097039; Thu, 7 Oct 2004 07:32:03 -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 i97EW3Vn097038; Thu, 7 Oct 2004 07:32:03 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97EW2ni097032 for ; Thu, 7 Oct 2004 07:32:02 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so135709rnl for ; Thu, 07 Oct 2004 07:32:04 -0700 (PDT) Received: by 10.38.1.71 with SMTP id 71mr2885309rna; Thu, 07 Oct 2004 07:32:04 -0700 (PDT) Received: by 10.38.65.11 with HTTP; Thu, 7 Oct 2004 07:32:04 -0700 (PDT) Message-ID: <14be96d3041007073255e696ba@mail.gmail.com> Date: Thu, 7 Oct 2004 10:32:04 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Dare Obasanjo Subject: Re: PaceReformedContent3 Cc: Atom-Syntax Syntax In-Reply-To: <20041005151456.49192.qmail@web41204.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041005151456.49192.qmail@web41204.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 5 Oct 2004 08:14:56 -0700 (PDT), Dare Obasanjo wrote: > Frankly I think that's still too much. You can get > away with just supporting HTML. I think we've put up with your tripe long enough in this thread. Blogger, Typepad, Moveable Type, Wordpress... all of these tools generate plain text content feeds by default. Some have specific fields for user-entered data, others auto-generate plain text in a variety of ways ranging from passable to laughable. Regardless, plain text content is the single most popular use case for feeds. > The only real > difference between text and HTML to authoring tools > will be using   and
for spaces and newlines > respectively. If you insist on obfuscating the distinction between text and HTML, may I recommend an alternate syndication format? There is one that I believe would meet your requirements precisely. It has several mailing lists devoted to it, with more being created all the time. The rest of us on *this* mailing list have different requirements, and we will continue to work towards creating a format that enables things outside the narrow scope of your vision. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu Oct 7 13:20:07 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 NAA06377 for ; Thu, 7 Oct 2004 13:20: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 i97H8j1s009928; Thu, 7 Oct 2004 10:08:45 -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 i97H8jxM009927; Thu, 7 Oct 2004 10:08:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97H8i6u009901 for ; Thu, 7 Oct 2004 10:08:45 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 8 Oct 2004 03:08:13 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 08 Oct 2004 03:08:14 +1000 Subject: feeds are not just for html... From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i97H8j6u009922 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Anyone who thinks feeds are just a proxy for a web page are limiting themselves... from http://www.decafbad.com/blog/2004/10/07/podcastinghype > So, in come iPodderX and friends. They¹re feed aggregators specifically built > to slurp down audio enclosures and sync them up to audio players like the > iPod. The idea is that, when you leave home, you take the digital audio player > with you, loaded up with your own personal radio programming. Not having an > iPod, I¹ve been queuing these aggregated audio posts up in iTunes at work, and > I¹ve been playing around with burning CDRW¹s for use in my car¹s in-dash MP3 > player. Once I get a headphone adapter for my Treo 600, maybe I¹ll start > listening to them on there. [1] http://ipodderx.com/ [2] http://www.ipodder.org/directory/4/ipodderSoftware From owner-atom-syntax@mail.imc.org Thu Oct 7 13:22:27 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 NAA06524 for ; Thu, 7 Oct 2004 13:22:26 -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 i97HFLnP010622; Thu, 7 Oct 2004 10:15: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 i97HFLbp010621; Thu, 7 Oct 2004 10:15:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97HFKft010614 for ; Thu, 7 Oct 2004 10:15:20 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 8 Oct 2004 03:15:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 08 Oct 2004 03:15:20 +1000 Subject: PaceDateOfSubject From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Abstract Define a Date Construct to hold a publisher-selected date which is the date of the subject of the entry. This date is not tied to an event in the publishing process. While inspired in part by PaceDateSubjective, this pace has been more refined, and the definition and use-case semantics narrowed. http://www.intertwingly.net/wiki/pie/PaceDateOfSubject (it's kinda long, so I won't post it all here) From owner-atom-syntax@mail.imc.org Thu Oct 7 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 OAA08591 for ; Thu, 7 Oct 2004 14:20:59 -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 i97IDONQ014894; Thu, 7 Oct 2004 11:13: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 i97IDO56014893; Thu, 7 Oct 2004 11:13:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97IDOoD014886 for ; Thu, 7 Oct 2004 11:13:24 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 915F44F285; Thu, 7 Oct 2004 14:13:27 -0400 (EDT) Date: Thu, 7 Oct 2004 14:13:27 -0400 From: Dan Brickley To: Dare Obasanjo Cc: Eric Scheid , Atom Syntax Subject: Re: feeds are not just for html... Message-ID: <20041007181327.GC32434@homer.w3.org> References: <20041007174811.49375.qmail@web41201.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041007174811.49375.qmail@web41201.mail.yahoo.com> User-Agent: Mutt/1.5.6+20040722i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Dare Obasanjo [2004-10-07 10:48-0700] > > > --- Eric Scheid wrote: > > > > > Anyone who thinks feeds are just a proxy for a web > > page are limiting > > themselves... > > Oh look, it's the Strawman argument right on cue. > Looks like you've been taking lessons from the Mark > Pilgrim school of debating. Regarding 'debating style', there's imho no need for this snipey style of interaction here. Perhaps you and Eric and Mark know each other very well and there's an implicit, friendly smile behind this exchange, but for those folks who aren't in the loop, such talk can sour the atmosphere and discourage participation. Dan From owner-atom-syntax@mail.imc.org Thu Oct 7 14:43: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 OAA10477 for ; Thu, 7 Oct 2004 14:43:45 -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 i97IVGlX016250; Thu, 7 Oct 2004 11:31: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 i97IVGHD016249; Thu, 7 Oct 2004 11:31:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i97IVF0b016231 for ; Thu, 7 Oct 2004 11:31:15 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 26146 invoked by uid 65534); 7 Oct 2004 18:31:13 -0000 Received: from dsl-082-082-072-023.arcor-ip.net (EHLO voyager) (82.82.72.23) by mail.gmx.net (mp013) with SMTP; 07 Oct 2004 20:31:13 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Eric Scheid Cc: Atom Syntax Subject: Re: PaceDateOfSubject Date: Thu, 07 Oct 2004 20:30:58 +0200 Message-ID: <418082d8.633597064@smtp.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Eric Scheid wrote: >http://www.intertwingly.net/wiki/pie/PaceDateOfSubject Our charter states [...] it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents. [...] Yet much of the rationale seems to disagree with our charter, there are arguments like if this is added there is no need for extensions (which is true for any meta data) and it is said that publishers will be forced to hijack some other meta data mechanism for this purpose (which seems again true for any meta data not in the core documents). Maybe such arguments can be replaced by a more convincing argument why this meta data in particular is most basic, generic metadata or at least very close to that? I am opposed to this Pace as it is not sufficiently generic; it does not allow me to associate 08 November 2004 to an entry, I rather have to use 08 November 2004 07:00:00 UTC which means I would have to make some time up just to use it which further means that localizing the date to local time zones might yield in false information, a reader in some distant time zone might read the data as 07 November 2004 which would be bad for the birthday use case, for example. The lack of date ranges, for which there is no rationale in the Pace, has all the negative side effects the Pace cites as rationale for the element in general, [...] Doesn't mean someone couldn't write an entry titled "Start of Six Day War" and put the starting date into subject-date. [...] "hijacks" the atom:title element to encode additional meta data which the Pace considers a bad idea. I would not want to munge atom:title elements that way just to circumvent shortcomings of the element. A typical use case for such information in "event feeds" would be exporting such information into some calendar or schedule application, such functionality would however depend that users can use it in a convenient manner and beeing asked about time zones and having to modify the imported entries to cover the actual duration of the event would likely be annoying. I would support constructs with similar semantics that allow for less specific dates (or rather, actual dates not date+time combinations) and ranges of dates and/or date+time combinations to cover complete events. From owner-atom-syntax@mail.imc.org Thu Oct 7 15:45: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 PAA16621 for ; Thu, 7 Oct 2004 15:45:34 -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 i97JYgqI021186; Thu, 7 Oct 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 i97JYgXq021184; Thu, 7 Oct 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 cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97JYeuv021163 for ; Thu, 7 Oct 2004 12:34:41 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-7654.l5.c1.dsl.pol.co.uk ([84.66.29.230] helo=[192.168.0.2]) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.14) id 1CFe28-0000TI-45 for atom-syntax@imc.org; Thu, 07 Oct 2004 20:34:36 +0100 Message-ID: <41659351.7090305@isofarro.uklinux.net> Date: Thu, 07 Oct 2004 20:04:49 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceReformedContent3 References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> In-Reply-To: <4163FE36.70405@nokia.com> 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 Janne Jalkanen wrote: [Accessible alternatives] > I just have this nagging fear that if we require this, many > authors will just link to empty or useless representations to > satisfy the syntax requirements or just ignore it altogether, > producing broken feeds. And the blind will be screwed in > either case. Empty representations may be the correct alternative in a number of instances. Useless representations is something else. Reducing an accessible alternative from a must to a "really really should" would create an unneccessarily bigger barrier to access. It would give authors an excuse to ignore accessibility requirements instead of determining whether the content they provide does have accessible alternatives. By not requiring accessible alternatives, the specification is the tool that is screwing the blind. By requiring accessible alternatives, the author - or the tool he has chosen - is the one screwing the blind. > It's much like the "alt" attribute for is being used > these days - I can't count the :s I've seen... It > should be a VERY STRONG SHOULD, but not a MUST. You say that (alt="") as if it is a bad thing. There are valid and correct uses for alt="". I see more problems with no alt attribute at all. An alt attribute on an image is mandatory according to the current HTML specification. How is reducing the requirement of an accessible alternative to a "SHOULD" going to be an improvement for the end-user? Mike. From owner-atom-syntax@mail.imc.org Thu Oct 7 16:12: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 QAA19633 for ; Thu, 7 Oct 2004 16:12: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 i97JxfAs023008; Thu, 7 Oct 2004 12:59: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 i97JxfMb023007; Thu, 7 Oct 2004 12:59:41 -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 i97JxeMH022999 for ; Thu, 7 Oct 2004 12:59:40 -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 1CFeQM-0001ul-5b; Thu, 07 Oct 2004 19:59:38 +0000 Message-ID: <4165A02A.1000703@franklinmint.fm> Date: Thu, 07 Oct 2004 15:59:38 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Isofarro CC: Atom Syntax Subject: Re: PaceReformedContent3 References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> In-Reply-To: <41659351.7090305@isofarro.uklinux.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 Isofarro wrote: > > By not requiring accessible alternatives, the specification is > the tool that is screwing the blind. By requiring accessible > alternatives, the author - or the tool he has chosen - is the one > screwing the blind. No, the author is always responsible. PaceReformedContent3 provides a crystal-clear way of specifying accessible alternatives, the tag. Linking is granular enough because the title and summary must be text or (X)HTML, and there can be only one content element. Here is a sample entry: ... A Picture of My Trip To The Lake What improvements do you suggest? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 7 16:31:55 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 QAA22608 for ; Thu, 7 Oct 2004 16:31:54 -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 i97KLMev024543; Thu, 7 Oct 2004 13:21:22 -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 i97KLM2K024542; Thu, 7 Oct 2004 13:21:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server1.livestoryboard.com (livestoryboard.com [209.61.132.12] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97KLMrQ024536 for ; Thu, 7 Oct 2004 13:21:22 -0700 (PDT) (envelope-from rob@koberg.com) Received: from [127.0.0.1] (livestoryboard.com [209.61.132.12] (may be forged)) (authenticated) by server1.livestoryboard.com (8.11.6/8.11.6) with ESMTP id i97KSrx18606 for ; Thu, 7 Oct 2004 15:28:53 -0500 Message-ID: <4165A506.7020803@koberg.com> Date: Thu, 07 Oct 2004 13:20:22 -0700 From: Robert Koberg User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: valid dates... References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> In-Reply-To: <4165A02A.1000703@franklinmint.fm> 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 Why is this date invalid: 2004-10-07T12:00:00 ? And this date valid: 2004-10-07T12:00:00Z I understand the w3 spec says it is so, but why? It is easy enough to work around, but I don't understand what it adds. thanks, -Rob From owner-atom-syntax@mail.imc.org Thu Oct 7 16:46:19 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 QAA24349 for ; Thu, 7 Oct 2004 16:46: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 i97HmDKf013387; Thu, 7 Oct 2004 10:48: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 i97HmDKp013386; Thu, 7 Oct 2004 10:48:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i97HmC2P013374 for ; Thu, 7 Oct 2004 10:48:12 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041007174811.49375.qmail@web41201.mail.yahoo.com> Received: from [207.46.238.146] by web41201.mail.yahoo.com via HTTP; Thu, 07 Oct 2004 10:48:11 PDT Date: Thu, 7 Oct 2004 10:48:11 -0700 (PDT) From: Dare Obasanjo Subject: Re: feeds are not just for html... To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > Anyone who thinks feeds are just a proxy for a web > page are limiting > themselves... Oh look, it's the Strawman argument right on cue. Looks like you've been taking lessons from the Mark Pilgrim school of debating. I don't think anyone on this list has argued that feeds are only for syndicating HTML. After all, even RSS can syndicate either HTML or arbitrary media types via enclosures. The points are (a) whether you really need three types for textual content (plain text, HTML and XHTML) when less would do and (b)if syndicating rich media one should provide more accessible alternatives. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 7 19:00: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 TAA07451 for ; Thu, 7 Oct 2004 19:00:50 -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 i97MpdsD034631; Thu, 7 Oct 2004 15:51:39 -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 i97MpdgU034630; Thu, 7 Oct 2004 15:51:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97MpcK0034623 for ; Thu, 7 Oct 2004 15:51:38 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8D25F4F1B6; Thu, 7 Oct 2004 18:51:42 -0400 (EDT) Message-Id: <4.2.0.58.J.20041008065934.06274c60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 08 Oct 2004 07:05:00 +0900 To: Robert Koberg , Atom Syntax From: Martin Duerst Subject: Re: valid dates... In-Reply-To: <4165A506.7020803@koberg.com> References: <4165A02A.1000703@franklinmint.fm> <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> Mime-Version: 1.0 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 13:20 04/10/07 -0700, Robert Koberg wrote: >Why is this date invalid: > >2004-10-07T12:00:00 > >? And this date valid: > >2004-10-07T12:00:00Z > >I understand the w3 spec says it is so, but why? > >It is easy enough to work around, but I don't understand what it adds. The first does not have a timezone. So within a period of about 26 hours, it's not clear what time exactly this denotes. The second has a timezone, so it is a very precisely defined point in time, up to a second. A day has 86400 seconds, so this is a difference in precision of about five orders of magnitude. More specifically, the later allows atom items to be ordered quite precisely timewise, while the former would lead to a lot of confusion by users if a tool claimed to have ordered the items timewise. Regards, Martin. From owner-atom-syntax@mail.imc.org Thu Oct 7 19:01:50 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 TAA07626 for ; Thu, 7 Oct 2004 19:01:49 -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 i97MpeB0034641; Thu, 7 Oct 2004 15:51: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 i97Mpex9034640; Thu, 7 Oct 2004 15:51:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97Mpeok034634 for ; Thu, 7 Oct 2004 15:51:40 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 6925E4F1B6; Thu, 7 Oct 2004 18:51:44 -0400 (EDT) Message-Id: <4.2.0.58.J.20041008070530.062894e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 08 Oct 2004 07:07:08 +0900 To: Tim Bray From: Martin Duerst Subject: Re: PaceReformedContent3 Cc: Atom Syntax In-Reply-To: <4165A02A.1000703@franklinmint.fm> References: <41659351.7090305@isofarro.uklinux.net> <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> Mime-Version: 1.0 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 15:59 04/10/07 -0400, Robert Sayre wrote: >Here is a sample entry: > > >... >A Picture of My Trip To The Lake > > Hello Tim, I suggest to use the above example instead of the bloody example currently in the pace, maybe with the tweak of writing "from My Trip" rather than "of My Trip". Regards, Martin. From owner-atom-syntax@mail.imc.org Thu Oct 7 19:31: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 TAA10546 for ; Thu, 7 Oct 2004 19:31: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 i97NNYOJ036970; Thu, 7 Oct 2004 16:23: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 i97NNYl6036969; Thu, 7 Oct 2004 16:23:34 -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 i97NNYs5036963 for ; Thu, 7 Oct 2004 16:23:34 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CFhbi-0005dJ-QX; Thu, 07 Oct 2004 23:23:34 +0000 Message-ID: <4165CFF5.9000003@franklinmint.fm> Date: Thu, 07 Oct 2004 19:23:33 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray , Atom Syntax Subject: Re: PaceReformedContent3 References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > On Oct 7, 2004, at 12:59 PM, Robert Sayre wrote: > >> PaceReformedContent3 provides a crystal-clear way of specifying >> accessible alternatives, the tag. Linking is >> granular enough because the title and summary must be text or (X)HTML, >> and there can be only one content element. >> >> Here is a sample entry: >> >> >> ... >> A Picture of My Trip To The Lake >> >> > > > Huh? ReformedContent3 doesn't talk about , and > furthermore says that if you have you MUST have > . Which I thought was an acceptable accessability > framework. It is my understanding that, by itself, it may not be. A summary is not an adequate substitute for the content itself, but it is good practice to provide it. Complete accessibility success may not be possible[1]. PaceReformedContent3 works with because the relationship between the entry and the alternate resource is sufficiently granular [0]. IMHO, there is no need to conflate containment with accessibility, especially when the inaccessible content also requires a URI to be dereferenced. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg09363.html [1] http://www.w3.org/TR/2004/WD-WCAG20-20040730/ From owner-atom-syntax@mail.imc.org Fri Oct 8 02:19:56 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 CAA26401 for ; Fri, 8 Oct 2004 02:19:56 -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 i9862oTe091297; Thu, 7 Oct 2004 23:02: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 i9862olc091295; Thu, 7 Oct 2004 23:02:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9862mTs091279 for ; Thu, 7 Oct 2004 23:02:49 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9862tW26860 for ; Fri, 8 Oct 2004 09:02:55 +0300 (EET DST) X-Scanned: Fri, 8 Oct 2004 09:02:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9862Mu8026532 for ; Fri, 8 Oct 2004 09:02:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00lyP9aQ; Fri, 08 Oct 2004 09:02:21 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9862KY16465 for ; Fri, 8 Oct 2004 09:02:20 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Oct 2004 09:02:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Oct 2004 09:02:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PaceReformedContent3 Date: Fri, 8 Oct 2004 09:01:42 +0300 Message-ID: Thread-Topic: PaceReformedContent3 Thread-Index: AcSsp2+kEUd9XmcPTsCgtaNg8ffofgAUpCaQ From: To: X-OriginalArrivalTime: 08 Oct 2004 06:02:12.0357 (UTC) FILETIME=[5A844350:01C4ACFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9862oTs091288 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > By not requiring accessible alternatives, the specification is > the tool that is screwing the blind. By requiring accessible > alternatives, the author - or the tool he has chosen - is the > one screwing the blind. I think that Robert put it very nicely - the should be an adequate lowest-common-denominator representation of the content, with no need for an extra alternative format. So perhaps we should reword this into "In an Atom Entry, you MUST Have either a <title>or <link rel="alternative"> to provide a textual representation. You MAY also have both." Besides, in those cases where the content in itself is fully accessible to even the blindest of users, requiring a <link rel="alternative"> seems kinda stupid. Or in those cases where you are just providing a headline, but no content. If you have no content, how can you provide an alternative representation of it? > You say that (alt="") as if it is a bad thing. There are valid > and correct uses for alt="". I see more problems with no alt > attribute at all. ...which is exactly happening in very, very many web sites. > An alt attribute on an image is mandatory according to the > current HTML specification. How is reducing the requirement of > an accessible alternative to a "SHOULD" going to be an > improvement for the end-user? ...because requiring ALT resulted in a bunch of malformed web sites, where the developers just did not care. /Janne From owner-atom-syntax@mail.imc.org Fri Oct 8 06:02: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 GAA09158 for <atompub-archive@lists.ietf.org>; Fri, 8 Oct 2004 06:02:24 -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 i989aLIP095435; Fri, 8 Oct 2004 02:36: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 i989aLMB095434; Fri, 8 Oct 2004 02:36:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fw1-qfe0.mfie.gov.ma ([194.204.211.1]) by above.proper.com (8.12.11/8.12.9) with SMTP id i989Zskj095302 for <atom-syntax@imc.org>; Fri, 8 Oct 2004 02:36:16 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [10.116.2.100] by fw1-qfe0.mfie.gov.ma via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Fri, 8 Oct 2004 09:39:49 -0700 Date: Fri, 08 Oct 2004 09:39:25 +0000 To: "Atom-syntax" <atom-syntax@imc.org> From: "Rubys" <rubys@intertwingly.net> Subject: Re: Thanks :) Message-ID: <zoqorimioohpffvieec@imc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------bapimrquksclppexpjlg" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> ----------bapimrquksclppexpjlg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> :) <br> </body></html> ----------bapimrquksclppexpjlg Content-Type: application/octet-stream; name="price.scr" Content-Disposition: attachment; filename="price.scr" Content-Transfer-Encoding: base64 ----------bapimrquksclppexpjlg-- From owner-atom-syntax@mail.imc.org Fri Oct 8 09:20: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 JAA22165 for <atompub-archive@lists.ietf.org>; Fri, 8 Oct 2004 09:20:32 -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 i98D52ps035507; Fri, 8 Oct 2004 06:05: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 i98D5267035506; Fri, 8 Oct 2004 06:05:02 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98D51EG035495 for <atom-syntax@imc.org>; Fri, 8 Oct 2004 06:05:02 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so38118rnl for <atom-syntax@imc.org>; Fri, 08 Oct 2004 06:04:58 -0700 (PDT) Received: by 10.38.89.69 with SMTP id m69mr139407rnb; Fri, 08 Oct 2004 06:04:58 -0700 (PDT) Received: by 10.38.65.11 with HTTP; Fri, 8 Oct 2004 06:04:58 -0700 (PDT) Message-ID: <14be96d304100806044f7b4bd2@mail.gmail.com> Date: Fri, 8 Oct 2004 09:04:58 -0400 From: Mark Pilgrim <pilgrim@gmail.com> Reply-To: Mark Pilgrim <pilgrim@gmail.com> To: "janne.jalkanen@nokia.com" <janne.jalkanen@nokia.com> Subject: Re: PaceReformedContent3 Cc: atom-syntax@imc.org In-Reply-To: <AE6D9B5454ED25459054C8160954B476140AB3@esebe105.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <AE6D9B5454ED25459054C8160954B476140AB3@esebe105.NOE.Nokia.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Fri, 8 Oct 2004 09:01:42 +0300, janne.jalkanen@nokia.com <janne.jalkanen@nokia.com> wrote: > > > By not requiring accessible alternatives, the specification is > > the tool that is screwing the blind. By requiring accessible > > alternatives, the author - or the tool he has chosen - is the > > one screwing the blind. > > I think that Robert put it very nicely - the <title> should be an adequate lowest-common-denominator representation of the content, with no need for an extra alternative format. This is not an acceptable solution. Go read http://www.w3.org/TR/xag > > You say that (alt="") as if it is a bad thing. There are valid > > and correct uses for alt="". I see more problems with no alt > > attribute at all. > > ...which is exactly happening in very, very many web sites. There are also many web sites that use the alt attribute correctly and are accessible to the blind. This would be impossible without the existence of the alt attribute. > > > An alt attribute on an image is mandatory according to the > > current HTML specification. How is reducing the requirement of > > an accessible alternative to a "SHOULD" going to be an > > improvement for the end-user? > > ...because requiring ALT resulted in a bunch of malformed web sites, where the developers just did not care. This is a non-sequiter. Isofarro had it right. If individual authors choose to publish inaccessible content, that is an education/advocacy problem. If individual authors are unable to publish accessible content, that is a specification problem. Accessibility is not optional. Our co-chair agrees with me that this is a baseline requirement. Our content model will be accessible (in fact, it will be *more* accessible than the stupid alt attribute in HTML, which only allows plain text). -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri Oct 8 09:26:13 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 JAA22686 for <atompub-archive@lists.ietf.org>; Fri, 8 Oct 2004 09:26:13 -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 i98DFOBl036276; Fri, 8 Oct 2004 06:15: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 i98DFOhZ036275; Fri, 8 Oct 2004 06:15:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98DFNRP036269 for <atom-syntax@imc.org>; Fri, 8 Oct 2004 06:15:23 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 5225 invoked from network); 8 Oct 2004 13:15:23 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender <wkearney@syndic8.com>) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for <rob@koberg.com>; 8 Oct 2004 13:15:23 -0000 Message-ID: <0b5a01c4ad38$df4e21f0$200ca8c0@wkearney.com> From: "Bill Kearney" <wkearney@syndic8.com> To: "Robert Koberg" <rob@koberg.com>, "Atom Syntax" <atom-syntax@imc.org> References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> <4165A506.7020803@koberg.com> Subject: Re: valid dates... Date: Fri, 8 Oct 2004 09:15:24 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > Why is this date invalid: > 2004-10-07T12:00:00 > ? And this date valid: > 2004-10-07T12:00:00Z > > I understand the w3 spec says it is so, but why? > It is easy enough to work around, but I don't understand what it adds. The first timestamp lacks a zone. Without that timezone it's not possible to tell "when" that instant in time expresses. Think of it this way, these are all exactly the same instant in time: 2004-10-08T02:00:00-0400 2004-10-07T23:00:00-0700 2004-10-07T06:00:00Z That's 2am EDT on Friday in Washington, DC, 11pm on Thursday in California and 6 in the morning UTC. If you just left off the timezone you'd be unable to tell when and could end up with 26 different guesses about it. Was your time noon in California and thus early evening in London? Or noon in Tokyo and the middle of the night in New York? And don't get me started on date calculations when timezone shifts for daylight savings are applied... -Bill Kearney From owner-atom-syntax@mail.imc.org Fri Oct 8 10:02: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 KAA24956 for <atompub-archive@lists.ietf.org>; Fri, 8 Oct 2004 10:02: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 i98Dp0Jn038649; Fri, 8 Oct 2004 06:51:00 -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 i98Dp0AP038648; Fri, 8 Oct 2004 06:51:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server1.livestoryboard.com (livestoryboard.com [209.61.132.12] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98Doxm1038639 for <atom-syntax@imc.org>; Fri, 8 Oct 2004 06:50:59 -0700 (PDT) (envelope-from rob@koberg.com) Received: from [127.0.0.1] (livestoryboard.com [209.61.132.12] (may be forged)) (authenticated) by server1.livestoryboard.com (8.11.6/8.11.6) with ESMTP id i98DwWx27504 for <atom-syntax@imc.org>; Fri, 8 Oct 2004 08:58:32 -0500 Message-ID: <41669B04.4020108@koberg.com> Date: Fri, 08 Oct 2004 06:49:56 -0700 From: Robert Koberg <rob@koberg.com> User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: valid dates... References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> <4165A506.7020803@koberg.com> <0b5a01c4ad38$df4e21f0$200ca8c0@wkearney.com> In-Reply-To: <0b5a01c4ad38$df4e21f0$200ca8c0@wkearney.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit OK - thanks to all who responded. I had been thinking of my own needs where I only care if something is before or after a dateTime. What is the best practice in the following situation: My webapp (online content management) consists of projects which consist of user/authors. Authors in the same project might be (are) in different timezones internationally. My servers are in the US central timezone and the webapp uses their dateTime for created, modified and published date. Is it OK or deceptive to use the servers dateTime and simply append the 'Z' (which is what I am currently doing)? In other words, does it matter which timezone you use, just so you use one? Should I make the effort (for newsfeeds) to add/subtract time from the US central timezone based on the project and/or author user's timezone? What would you do? thanks, -Rob From owner-atom-syntax@mail.imc.org Fri Oct 8 10:25: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 KAA28433 for <atompub-archive@lists.ietf.org>; Fri, 8 Oct 2004 10:25: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 i98ED4oC040424; Fri, 8 Oct 2004 07:13:04 -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 i98ED4o7040423; Fri, 8 Oct 2004 07:13:04 -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 i98ED3Lh040417 for <atom-syntax@imc.org>; Fri, 8 Oct 2004 07:13:03 -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 1CFvUO-0006Hf-Oa; Fri, 08 Oct 2004 14:12:56 +0000 Message-ID: <4166A063.8040906@franklinmint.fm> Date: Fri, 08 Oct 2004 10:12:51 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim <pilgrim@gmail.com> CC: "janne.jalkanen@nokia.com" <janne.jalkanen@nokia.com>, atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <AE6D9B5454ED25459054C8160954B476140AB3@esebe105.NOE.Nokia.com> <14be96d304100806044f7b4bd2@mail.gmail.com> In-Reply-To: <14be96d304100806044f7b4bd2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: > On Fri, 8 Oct 2004 09:01:42 +0300, janne.jalkanen@nokia.com > <janne.jalkanen@nokia.com> wrote: > >>>By not requiring accessible alternatives, the specification is >>>the tool that is screwing the blind. By requiring accessible >>>alternatives, the author - or the tool he has chosen - is the >>>one screwing the blind. >> >>I think that Robert put it very nicely - the <title> should be an adequate lowest-common-denominator representation of the content, with no need for an extra alternative format. > > > This is not an acceptable solution. > I asked for an acceptable solution. Show me one. Here is a sample entry, which demonstrates a very common use case: <entry> ... <title>A Picture of My Trip To The Lake How do we improve this? Would including a summary make it better? > >>>You say that (alt="") as if it is a bad thing. There are valid >>>and correct uses for alt="". I see more problems with no alt >>>attribute at all. >> >>...which is exactly happening in very, very many web sites. > > > There are also many web sites that use the alt attribute correctly and > are accessible to the blind. This would be impossible without the > existence of the alt attribute. > It would still be possible if the alt attribute were optional. > >>>An alt attribute on an image is mandatory according to the >>>current HTML specification. How is reducing the requirement of >>>an accessible alternative to a "SHOULD" going to be an >>>improvement for the end-user? >> >>...because requiring ALT resulted in a bunch of malformed web sites, where the developers just did not care. > > > This is a non-sequiter. Isofarro had it right. If individual authors > choose to publish inaccessible content, that is an education/advocacy > problem. If individual authors are unable to publish accessible > content, that is a specification problem. Isofarro stated that the spec "screws the blind" if it doesn't include a validity constraint that requires some sort of "alternative" element or attribute. If such an element is available, but not a validity constraint, are we still "screwing the blind"? It seems like a judgement call for the author to make, based on the nature of the content. > > Accessibility is not optional. Our co-chair agrees with me that this > is a baseline requirement. Our content model will be accessible (in > fact, it will be *more* accessible than the stupid alt attribute in > HTML, which only allows plain text). > Everyone agrees that this is a baseline requirement. I want to do the right thing. Please explain why a validity constraint is the right thing. > Go read http://www.w3.org/TR/xag OK, I read that. Where does it talk about validity constraints? In particular, I noted "1.1 Provide a mechanism to explicitly associate alternatives for content or content fragments." It does not say "require a mechanism". Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 8 10:34:40 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 KAA29637 for ; Fri, 8 Oct 2004 10:34:39 -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 i98EOE9M041322; Fri, 8 Oct 2004 07:24:14 -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 i98EOE70041321; Fri, 8 Oct 2004 07:24:14 -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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98EOCOW041303 for ; Fri, 8 Oct 2004 07:24:12 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so53876rnl for ; Fri, 08 Oct 2004 07:24:04 -0700 (PDT) Received: by 10.38.75.38 with SMTP id x38mr180708rna; Fri, 08 Oct 2004 07:24:04 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Fri, 8 Oct 2004 07:24:04 -0700 (PDT) Message-ID: <540e3732041008072439446032@mail.gmail.com> Date: Fri, 8 Oct 2004 09:24:04 -0500 From: "Roger B." Reply-To: "Roger B." To: Robert Koberg Subject: Re: valid dates... Cc: Atom Syntax In-Reply-To: <41669B04.4020108@koberg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> <4165A506.7020803@koberg.com> <0b5a01c4ad38$df4e21f0$200ca8c0@wkearney.com> <41669B04.4020108@koberg.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Is it OK or deceptive to use the servers dateTime and simply append the > 'Z' (which is what I am currently doing)? Rob: Deceptive? Sure, since it *is* misleading. Okay? That depends... are you comfortable with consumers of your data working with dates that are misleading? The biggest practical impact will come when entries from your feed are blended with others in an aggregator. Your entries will sort into a slot that's five or six hours off from where they should actually be. > What would you do? I switched to using UTC internally, because that was the easiest approach for my existing code. YMMV. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Oct 8 11:00: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 LAA02009 for ; Fri, 8 Oct 2004 11:00:29 -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 i98EnOYN043338; Fri, 8 Oct 2004 07:49: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 i98EnOnk043337; Fri, 8 Oct 2004 07:49:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98EnNln043328 for ; Fri, 8 Oct 2004 07:49:23 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 12902 invoked from network); 8 Oct 2004 14:49:23 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Oct 2004 14:49:23 -0000 Message-ID: <0c0d01c4ad46$0176b7d0$200ca8c0@wkearney.com> From: "Bill Kearney" To: "'Atom Syntax'" References: <20041005193004.8524.qmail@web41204.mail.yahoo.com> <4163FE36.70405@nokia.com> <41659351.7090305@isofarro.uklinux.net> <4165A02A.1000703@franklinmint.fm> <4165A506.7020803@koberg.com> <0b5a01c4ad38$df4e21f0$200ca8c0@wkearney.com> <41669B04.4020108@koberg.com> Subject: Re: valid dates... Date: Fri, 8 Oct 2004 10:49:15 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > OK - thanks to all who responded. I had been thinking of my own needs > where I only care if something is before or after a dateTime. You say that now. Wait until you've got a ton of stuff stacked up and need to interop with other systems.... > What is the best practice in the following situation: My webapp (online > content management) consists of projects which consist of user/authors. > Authors in the same project might be (are) in different timezones > internationally. My servers are in the US central timezone and the > webapp uses their dateTime for created, modified and published date. Track default timezones for each author and normalize any input to a 'server standard' timezone. That way all input/output routines will have to operate with the understanding that they're either always showing 'server time' or take steps to localize it for the user. Most portal tools do this already, letting the user select their own timezone and adjusting all shown timestamps to use it. > Is it OK or deceptive to use the servers dateTime and simply append the > 'Z' (which is what I am currently doing)? Deceptive and wrong. Don't do it. > In other words, does it matter which timezone you use, just so > you use one? Decide what you're going to use internally and stick to it. It's often most useful to go with UTC as it's always the same regardless of seasonal shifts. Be very careful about time calculations when seasonal shifts are involved. 4pm in the summer is not the same as 4pm in the winter when shift-spanning intervals are involved. > Should I make the effort (for newsfeeds) to add/subtract > time from the US central timezone based > on the project and/or author user's timezone? > > What would you do? Decide on what timezone to use internally and stick with it. As long as you understand how well (or how poorly) your underlying tools handle timestamps it's not too hard to do it right. The difficulty lies in failing to grasp whether or not your tools handle timestamps in the ways you expect. -Bill Kearney From owner-atom-syntax@mail.imc.org Fri Oct 8 11:01:49 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 LAA02149 for ; Fri, 8 Oct 2004 11:01:48 -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 i98EjOSo043014; Fri, 8 Oct 2004 07:45: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 i98EjOSL043013; Fri, 8 Oct 2004 07:45:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98EjNgX043000 for ; Fri, 8 Oct 2004 07:45:23 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041008144518.77960.qmail@web41211.mail.yahoo.com> Received: from [24.19.154.62] by web41211.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 07:45:18 PDT Date: Fri, 8 Oct 2004 07:45:18 -0700 (PDT) From: Dare Obasanjo Subject: Re: valid dates... To: Robert Koberg Cc: Atom Syntax In-Reply-To: <41669B04.4020108@koberg.com> 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: --- Robert Koberg wrote: > > Is it OK or deceptive to use the servers dateTime > and simply append the > 'Z' (which is what I am currently doing)? In other > words, does it matter > which timezone you use, just so you use one? Should > I make the effort > (for newsfeeds) to add/subtract time from the US > central timezone based > on the project and/or author user's timezone? What matters is that you use the accurate time including timezone information. Whether the timezone is that of the server or the client machine making the post isn't really that relevant. For example, it isn't that important if you say 7:42 AM PST or 14:42 as long as there is a correct time in the feed that maps to the same instance in time as when the post was made. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Oct 8 11:22:19 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 LAA03650 for ; Fri, 8 Oct 2004 11:22:19 -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 i98FBI7n045111; Fri, 8 Oct 2004 08:11: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 i98FBIGQ045110; Fri, 8 Oct 2004 08:11:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98FBCLa045096 for ; Fri, 8 Oct 2004 08:11:12 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i98FBFui011998 for ; Fri, 8 Oct 2004 09:11:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I59005Z8U6QL8@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 08 Oct 2004 09:11:15 -0600 (MDT) Received: from [192.168.1.27] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5900L3VU6PNG@mail.sun.net> for atom-syntax@imc.org; Fri, 08 Oct 2004 09:11:14 -0600 (MDT) Date: Fri, 08 Oct 2004 08:11:27 -0700 From: Tim Bray Subject: Re: PaceReformedContent3 In-reply-to: <4166A063.8040906@franklinmint.fm> To: mint@franklinmint.fm Cc: Mark Pilgrim , "janne.jalkanen@nokia.com" , atom-syntax@imc.org Message-id: <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 8, 2004, at 7:12 AM, Robert Sayre wrote: > > ... > A Picture of My Trip To The Lake > > This is illegal per PaceReformedConetent3 because it doesn't have an . > Isofarro stated that the spec "screws the blind" if it doesn't include > a validity constraint that requires some sort of "alternative" element > or attribute. If such an element is available, but not a validity > constraint, are we still "screwing the blind"? It seems like a > judgement call for the author to make, based on the nature of the > content. We *have* a constraint: that atom:summary is required in any case where the content is not locally provided or is is not text/* or *xml. Thus, I claim the spec currently meets the bar for accessibility. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 8 11:29:39 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 LAA04571 for ; Fri, 8 Oct 2004 11:29:38 -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 i98FHIuR045625; Fri, 8 Oct 2004 08:17: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 i98FHIYb045624; Fri, 8 Oct 2004 08:17:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03.rdc-kc.rr.com (ms-smtp-03.rdc-kc.rr.com [24.94.166.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98FHGp4045618 for ; Fri, 8 Oct 2004 08:17:16 -0700 (PDT) (envelope-from csgallagher@wi.rr.com) Received: from xp1 (CPE-65-25-169-159.wi.rr.com [65.25.169.159]) by ms-smtp-03.rdc-kc.rr.com (8.12.10/8.12.7) with ESMTP id i98FHGjE007420 for ; Fri, 8 Oct 2004 10:17:17 -0500 (CDT) Message-Id: <200410081517.i98FHGjE007420@ms-smtp-03.rdc-kc.rr.com> Reply-To: From: "Clinton Gallagher" To: "'Atom Syntax'" Date: Fri, 8 Oct 2004 10:17:11 -0500 Organization: METROmilwaukee MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcStSeAzgjVrTJ39TceyQFJhho6OQQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit help From owner-atom-syntax@mail.imc.org Fri Oct 8 11:51:56 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 LAA06332 for ; Fri, 8 Oct 2004 11:51:55 -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 i98FeLCG047320; Fri, 8 Oct 2004 08:40: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 i98FeL0V047319; Fri, 8 Oct 2004 08:40:21 -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 i98FeLN5047312 for ; Fri, 8 Oct 2004 08:40:21 -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 1CFwqn-00024j-Hr; Fri, 08 Oct 2004 15:40:09 +0000 Message-ID: <4166B4D2.1080502@franklinmint.fm> Date: Fri, 08 Oct 2004 11:40:02 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Mark Pilgrim , "janne.jalkanen@nokia.com" , atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> In-Reply-To: <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > On Oct 8, 2004, at 7:12 AM, Robert Sayre wrote: > >> >> ... >> A Picture of My Trip To The Lake >> >> > > > This is illegal per PaceReformedConetent3 because it doesn't have an > . > >> Isofarro stated that the spec "screws the blind" if it doesn't include >> a validity constraint that requires some sort of "alternative" element >> or attribute. If such an element is available, but not a validity >> constraint, are we still "screwing the blind"? It seems like a >> judgement call for the author to make, based on the nature of the >> content. > > > We *have* a constraint: that atom:summary is required in any case where > the content is not locally provided or is is not text/* or *xml. Thus, > I claim the spec currently meets the bar for accessibility. -Tim > I know we have a constraint. I question whether the constraint helps accessibility. ... My First Program <img src="my_thumbnail.jpg"> Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 8 12:44: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 MAA09682 for ; Fri, 8 Oct 2004 12:44: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 i98GUunj050895; Fri, 8 Oct 2004 09:30: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 i98GUuU7050894; Fri, 8 Oct 2004 09:30:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98GUtPa050887 for ; Fri, 8 Oct 2004 09:30:55 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-7470.lns3-c7.dsl.pol.co.uk ([84.65.221.46] helo=[192.168.0.2]) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.14) id 1CFxdv-0002qH-Dj for atom-syntax@imc.org; Fri, 08 Oct 2004 17:30:55 +0100 Message-ID: <4166C100.8010407@isofarro.uklinux.net> Date: Fri, 08 Oct 2004 17:32:00 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> <4166B4D2.1080502@franklinmint.fm> In-Reply-To: <4166B4D2.1080502@franklinmint.fm> 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 Robert Sayre wrote: > Tim Bray wrote: >> We *have* a constraint: that atom:summary is required in any case >> where the content is not locally provided or is is not text/* or >> *xml. Thus, I claim the spec currently meets the bar for >> accessibility. -Tim > > I know we have a constraint. I question whether the constraint helps > accessibility. > > > ... > My First Program > <img src="my_thumbnail.jpg"> > > As I understand it, this meets the Atom part of the specification. But fails on the HTML part. If you are using an img element (as in the summary), then the alt attribute is required [1]. Interesting to compare your example against the specific WCAG 1.0 guideline to non-text content [2]: specifically: "This guideline emphasizes the importance of providing text equivalents of non-text content (images, pre-recorded audio, video)." The XML Accessibility Guidelines seem to correlate with this understanding, since references checkpoint 1.1 of the WCAG1.0 which is [3]: "Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content)." More to the point, accessibility can be improved by emphasising (as WCAG1.0 and XAG do) the importance of providing text equivalents to non-text content. I'd suggest also that or accessible HTML equivalents can be used instead of text where possible. So in case of the summary, the following should be sufficient: <img src="my_thumbnail.jpg" alt="My day job - dressed as a penguin"> Mike. [1] [2] [3] From owner-atom-syntax@mail.imc.org Fri Oct 8 13:11: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 NAA11812 for ; Fri, 8 Oct 2004 13:11: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 i98GxQa6053569; Fri, 8 Oct 2004 09:59:26 -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 i98GxQet053568; Fri, 8 Oct 2004 09:59:26 -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 i98GxPfI053561 for ; Fri, 8 Oct 2004 09:59:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CFy5U-000677-Vi; Fri, 08 Oct 2004 16:59:25 +0000 Message-ID: <4166C769.7010803@franklinmint.fm> Date: Fri, 08 Oct 2004 12:59:21 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Isofarro CC: atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> <4166B4D2.1080502@franklinmint.fm> <4166C100.8010407@isofarro.uklinux.net> In-Reply-To: <4166C100.8010407@isofarro.uklinux.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 Isofarro wrote: > > Robert Sayre wrote: >> My First Program >> <img src="my_thumbnail.jpg"> >> >> > > > As I understand it, this meets the Atom part of the specification. But > fails on the HTML part. If you are using an img element (as in the > summary), then the alt attribute is required [1]. Only in HTML 4, and note that I could have whitespace, linebreaks, or any other nonsense in there. > > Interesting to compare your example against the specific WCAG 1.0 > guideline to non-text content [2]: > > specifically: "This guideline emphasizes the importance of providing > text equivalents of non-text content (images, pre-recorded audio, video)." > > The XML Accessibility Guidelines seem to correlate with this > understanding, since references checkpoint 1.1 of the WCAG1.0 which is [3]: > > "Provide a text equivalent for every non-text element (e.g., via "alt", > "longdesc", or in element content)." We provide summary elements and links. It's also interesting to compare my point of view with the example XML dialect given in checkpoint 1.1 of the XAG document, SVG. "When a graphic does not include explanatory text content, it requires a text equivalent. If the equivalent is complex, use the 'desc' element, otherwise use the 'title' child element." -- http://www.w3.org/TR/SVG/access.html > > > More to the point, accessibility can be improved by emphasising (as > WCAG1.0 and XAG do) the importance of providing text equivalents to > non-text content. I'd suggest also that or accessible HTML equivalents > can be used instead of text where possible. > > So in case of the summary, the following should be sufficient: > > <img src="my_thumbnail.jpg" alt="My day job - > dressed as a penguin"> > I agree that we should emphasize it. It's not clear to me that required elements are a productive way to do that. We are still "providing" accessibility if the choice of elements are left to the author. Robert Sayre > > [1] > [2] > > > [3] > > From owner-atom-syntax@mail.imc.org Fri Oct 8 13:20:43 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 NAA12317 for ; Fri, 8 Oct 2004 13:20:42 -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 i98H8hlI054265; Fri, 8 Oct 2004 10:08:43 -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 i98H8hKS054264; Fri, 8 Oct 2004 10:08:43 -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 i98H8gxb054256 for ; Fri, 8 Oct 2004 10:08:42 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i98H9CCq001076 for ; Fri, 8 Oct 2004 13:09:12 -0400 Message-ID: <4166C99A.4040603@intertwingly.net> Date: Fri, 08 Oct 2004 13:08:42 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: New AtomPubIssuesList for 2004/10/08 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> In-Reply-To: <41546A46.60507@intertwingly.net> 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 The list this time is rather simple: the next Date item with the most listed supporters, and the biggest outstanding issue with the format. Given that we have been around these issues before, one thing I would like to ask is that people try to avoid making clever, provocative, and leading questions, and instead try to provide specific and constructive suggestions possible. So, the issues list at the moment is: PaceDateOfSubject PaceLinkAttrDefaults PaceLinkConstruct PaceLinkDelicious PaceLinkParent PaceLinkPurpose PaceLinkRelMechanism PaceLinkTitle PaceReplaceLinkElement - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Oct 8 13:50: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 NAA15322 for ; Fri, 8 Oct 2004 13:50:27 -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 i98HckrL057446; Fri, 8 Oct 2004 10:38: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 i98HckiT057445; Fri, 8 Oct 2004 10:38:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98HcjHQ057407 for ; Fri, 8 Oct 2004 10:38:45 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041008173843.10756.qmail@web41213.mail.yahoo.com> Received: from [67.160.45.9] by web41213.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 10:38:42 PDT Date: Fri, 8 Oct 2004 10:38:42 -0700 (PDT) From: Dare Obasanjo Subject: PaceLinkRelMechanism To: atom-syntax@imc.org 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: -1 on this Pace. As it is the values of the rel attribute do not have uniform semantics so there is no way for a client to consume a link element with a rel value it doesn't understand and have it do anything reasonable with it. This Pace basically looks like a way to create an extension mechanism that duplicates the ability to use extension elements. This redundancy alone is worth the -1. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 8 13:53: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 NAA15620 for ; Fri, 8 Oct 2004 13:53: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 i98Hja0N058164; Fri, 8 Oct 2004 10:45:36 -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 i98HjaWZ058163; Fri, 8 Oct 2004 10:45:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98HjarT058155 for ; Fri, 8 Oct 2004 10:45:36 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041008174533.98452.qmail@web41215.mail.yahoo.com> Received: from [67.160.45.9] by web41215.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 10:45:33 PDT Date: Fri, 8 Oct 2004 10:45:33 -0700 (PDT) From: Dare Obasanjo Subject: PaceLinkPurpose To: atom-syntax@imc.org 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: +1 on this Pace. Fold it into the spec, I agree 100% with the rationale. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:14:04 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 OAA17629 for ; Fri, 8 Oct 2004 14:14: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 i98I5psM059887; Fri, 8 Oct 2004 11:05:51 -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 i98I5pxL059886; Fri, 8 Oct 2004 11:05:51 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98I5p5i059876 for ; Fri, 8 Oct 2004 11:05:51 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so46332rnk for ; Fri, 08 Oct 2004 11:05:42 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr349638rnf; Fri, 08 Oct 2004 11:05:42 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:05:42 -0700 (PDT) Message-ID: <1f2ed5cd0410081105374f5fbb@mail.gmail.com> Date: Fri, 8 Oct 2004 20:05:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceLinkRelMechanism Cc: atom-syntax@imc.org In-Reply-To: <20041008173843.10756.qmail@web41213.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 to the Pace. As one of the original proponents of this Pace, I stand by the original aim - to provide some form of extensibility that has tighter constraints than 'anything in another namespace can go anywhere'. I haven't seen any other proposals that offer this in a better form. If there is no clear consensus on this I would suggest it be revisited with the extensible form of the rel attribute reduced to a simple URI. On Fri, 8 Oct 2004 10:38:42 -0700 (PDT), Dare Obasanjo wrote: > > -1 on this Pace. As it is the values of the rel > attribute do not have uniform semantics so there is no > way for a client to consume a link element with a rel > value it doesn't understand and have it do anything > reasonable with it. Uniform semantics are defined in the Pace (under 'Proposal'). > This Pace basically looks like a way to create an > extension mechanism that duplicates the ability to use > extension elements. This redundancy alone is worth the > -1. If by "extension elements" you mean elements from other namespaces that can go anywhere, this has been discussed before. The only redundancy is comparable to the pattern "microsoft.com" being redundant when you have the expression "*". Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:23: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 OAA18233 for ; Fri, 8 Oct 2004 14:23:05 -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 i98IEwx9060360; Fri, 8 Oct 2004 11:14:58 -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 i98IEwYE060359; Fri, 8 Oct 2004 11:14:58 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IEwTt060351 for ; Fri, 8 Oct 2004 11:14:58 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so46904rnk for ; Fri, 08 Oct 2004 11:14:50 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr356485rnf; Fri, 08 Oct 2004 11:14:50 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:14:50 -0700 (PDT) Message-ID: <1f2ed5cd04100811144da542b2@mail.gmail.com> Date: Fri, 8 Oct 2004 20:14:50 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceLinkPurpose Cc: atom-syntax@imc.org In-Reply-To: <20041008174533.98452.qmail@web41215.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008174533.98452.qmail@web41215.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +0. I like the idea of tightening the semantics, but "logically be presented to the user as clickable links" doesn't help much. At one extreme only GETtable hyperlinks fit the bill, at the other *anything* could be presented as a clickable link. "Links to other resources must be made using a different element." - so what would a logically clickable link be linking to?? (This is all aside from the reliance on a specific user interface component.) But if the definition can be made more useful, then I'd back this Pace, though would hope that the (controlled) extensibility point offered by 'rel' wasn't lost in the process. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:29:36 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 OAA18941 for ; Fri, 8 Oct 2004 14:29: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 i98IM7v4060732; Fri, 8 Oct 2004 11:22:07 -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 i98IM7VV060731; Fri, 8 Oct 2004 11:22:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IM6em060694 for ; Fri, 8 Oct 2004 11:22:07 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i98IKUiw028667; Fri, 8 Oct 2004 19:20:41 +0100 (BST) In-Reply-To: <20041008173843.10756.qmail@web41213.mail.yahoo.com> References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-840830460; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: PaceLinkRelMechanism Date: Fri, 8 Oct 2004 19:20:28 +0100 To: Dare Obasanjo X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-840830460 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Big -1 too. No one will implement this. Graham On 8 Oct 2004, at 6:38 pm, Dare Obasanjo wrote: > > -1 on this Pace. As it is the values of the rel > attribute do not have uniform semantics so there is no > way for a client to consume a link element with a rel > value it doesn't understand and have it do anything > reasonable with it. > > This Pace basically looks like a way to create an > extension mechanism that duplicates the ability to use > extension elements. This redundancy alone is worth the > -1. > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 > I will keep a special cache of low-tech weapons and train my troops in > their use. That way -- even if the heroes manage to neutralize my > power generator and/or render the standard-issue energy weapons > useless -- my troops will not be overrun by a handful of savages armed > with spears and rocks. > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com > --Apple-Mail-2-840830460 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA4MTgyMDI5WjAjBgkqhkiG9w0BCQQxFgQUVZP2D3AhOVGS/ETR3jMkqqDz joIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAFfJ71Ktc5NFvOHEoO5Jsr2Gn SlEid781IgH0LwF6ZAfTDwKLnmmADNSLe3UoS/cgeOEDOxcs7P737IQ4isbl1gHKQpMd4RX88ux2 jCnjJhCrqiL+ATpOXQuLeiucae+Wnw8CqPiH7WGXcV7uXRXdm4ykFdrBFJ1/PgwOJbiSCqHPe3W7 zQnYRPDHd1jxg/GRZUUuf80mcLuzAXv5/yVzHfUo3GhvOamjzdYt5ms/ZpM4z2g2Jg3Oag/LxT6X TyH7e1qQQKURjFqjYwh1S+1xMGBh3Ua7/HKbU6wkPLjJlI+78JEwLRvkuCcjSFBpwy1eNuLAmmu6 tiFKv3b8fWCJAAAAAAAAAA== --Apple-Mail-2-840830460-- From owner-atom-syntax@mail.imc.org Fri Oct 8 14:29:50 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 OAA19007 for ; Fri, 8 Oct 2004 14:29:50 -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 i98IN6mj060793; Fri, 8 Oct 2004 11:23: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 i98IN6kF060792; Fri, 8 Oct 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 mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IN5LK060785 for ; Fri, 8 Oct 2004 11:23:05 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so47405rnk for ; Fri, 08 Oct 2004 11:23:06 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr356065rnf; Fri, 08 Oct 2004 11:23:05 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:23:05 -0700 (PDT) Message-ID: <1f2ed5cd04100811234922ea3e@mail.gmail.com> Date: Fri, 8 Oct 2004 20:23:05 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceLinkAttrDefaults Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. At least in the context of the current specification. I'm all for the general idea of tightening up core elements (+1 on PaceServiceElement), but PaceLinkAttrDefaults seems way too far at present. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:32: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 OAA19252 for ; Fri, 8 Oct 2004 14:32: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 i98IQ0AJ060956; Fri, 8 Oct 2004 11:26:00 -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 i98IQ04H060955; Fri, 8 Oct 2004 11:26:00 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IQ0Gw060949 for ; Fri, 8 Oct 2004 11:26:00 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so47562rnk for ; Fri, 08 Oct 2004 11:26:03 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr360136rnf; Fri, 08 Oct 2004 11:26:03 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:26:03 -0700 (PDT) Message-ID: <1f2ed5cd04100811265a63a364@mail.gmail.com> Date: Fri, 8 Oct 2004 20:26:03 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceLinkConstruct Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 Again in the current context. This excessively overloads the syntax in terms of core functionality while losing the benefit of a controlled extension axis. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:36: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 OAA19689 for ; Fri, 8 Oct 2004 14:36:05 -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 i98ISU0U061105; Fri, 8 Oct 2004 11:28:30 -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 i98ISUo2061104; Fri, 8 Oct 2004 11:28:30 -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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98ISUeO061095 for ; Fri, 8 Oct 2004 11:28:30 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so47695rnk for ; Fri, 08 Oct 2004 11:28:28 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr360970rnf; Fri, 08 Oct 2004 11:28:28 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:28:28 -0700 (PDT) Message-ID: <1f2ed5cd04100811286b0aacb2@mail.gmail.com> Date: Fri, 8 Oct 2004 20:28:28 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceLinkDelicious Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +0. This is simply more evidence that an extensible relationship operator is needed. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:37: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 OAA19865 for ; Fri, 8 Oct 2004 14:37: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 i98IUfwx061261; Fri, 8 Oct 2004 11:30: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 i98IUfmO061260; Fri, 8 Oct 2004 11:30:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IUeOQ061248 for ; Fri, 8 Oct 2004 11:30:41 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i98IU1he000845 for ; Fri, 8 Oct 2004 19:30:01 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20041008174533.98452.qmail@web41215.mail.yahoo.com> References: <20041008174533.98452.qmail@web41215.mail.yahoo.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-841401949; protocol="application/pkcs7-signature" Message-Id: <117C86EB-1958-11D9-8095-000A2797ECDA@mac.com> From: Graham Subject: Re: PaceLinkPurpose Date: Fri, 8 Oct 2004 19:30:01 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3-841401949 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I like it but don't think it goes far enough, or that its wording is viable (clicakable/not-clickable is not a valid axis). There are basically 4 types of link: alternate - special case related - related, via, etc service image - favicons and logos We already have a special element for service (don't we?). The next step is to break out all the other types and drop the generic element completely. Graham --Apple-Mail-3-841401949 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA4MTgzMDAyWjAjBgkqhkiG9w0BCQQxFgQUNhCHXtbWmLsPC6EThp96fywa xp8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEALo7ZGzBdKF78cpF0Mdb60EVX GiCDjsaLSYfnEV1w5hmiSKZ7q6v11N+m+UF1dQrZ4NRr1qxLM4h9qC8vK1+icsxtjHn/qMT9rN/h GD/+emgFHltpDyfzrCkM4euMZSz/mB+AE0YhS+kLVUgPYZ3VsOleRKgX0GuUaQ5jByALaQAaAN2q f73vMa3xuec0htAKnPrj3QR6lqPnA7k2WOP0dkYAxOhpCGcU+rin3vOTPpiGMv3tu+6El2d23vsC cYuojcVAN8r+kffzwbs5VpshntIjcZgorvKa4d5kHBolLRmP0/578e3jNqL1DNpA61ka8K6wFVzg iX2PBCRVOfXc+wAAAAAAAA== --Apple-Mail-3-841401949-- From owner-atom-syntax@mail.imc.org Fri Oct 8 14:41:26 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 OAA20463 for ; Fri, 8 Oct 2004 14:41: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 i98IX7cf061434; Fri, 8 Oct 2004 11:33:07 -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 i98IX77f061433; Fri, 8 Oct 2004 11:33:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98IX7nA061426 for ; Fri, 8 Oct 2004 11:33:07 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041008183306.94827.qmail@web41205.mail.yahoo.com> Received: from [67.160.45.9] by web41205.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 11:33:06 PDT Date: Fri, 8 Oct 2004 11:33:06 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkPurpose To: Danny Ayers Cc: atom-syntax@imc.org In-Reply-To: <1f2ed5cd04100811144da542b2@mail.gmail.com> 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: --- Danny Ayers wrote: > > I like the idea of tightening the semantics, but > "logically be > presented to the user as clickable links" doesn't > help much. At one > extreme only GETtable hyperlinks fit the bill, at > the other *anything* > could be presented as a clickable link. I don't see where you get your other extreme from. How can *anything* be presented as a clickable link? Please give examples. > > But if the definition can be made more useful, then > I'd back this > Pace, though would hope that the (controlled) > extensibility point > offered by 'rel' wasn't lost in the process. Define more useful. As it is PaceLinkPurpose turns the most ambiguous and poorly designed aspect of Atom into a well-defined, consistent and usable extensibility point. How would you improve it? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:43:23 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 OAA20790 for ; Fri, 8 Oct 2004 14:43:22 -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 i98IZ97p061557; Fri, 8 Oct 2004 11:35:09 -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 i98IZ9Yu061556; Fri, 8 Oct 2004 11:35:09 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IZ8jb061549 for ; Fri, 8 Oct 2004 11:35:08 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so48074rnk for ; Fri, 08 Oct 2004 11:35:11 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr360071rnf; Fri, 08 Oct 2004 11:35:11 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:35:11 -0700 (PDT) Message-ID: <1f2ed5cd0410081135d7137c9@mail.gmail.com> Date: Fri, 8 Oct 2004 20:35:11 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceLinkRelMechanism Cc: Dare Obasanjo , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Implement what? Tools that only use the core definitions would check the value of any rel attribute against the rel list, exactly as they would have to in current circumstances. The only real difference would be the absence of an error message in a validator that checked the enuration. On the other hand, if you want to use the link element to associated an item with something shall we say like an mp3 file, then it's easily done. Cheers, Danny. On Fri, 8 Oct 2004 19:20:28 +0100, Graham wrote: > Big -1 too. No one will implement this. > > Graham > > > > On 8 Oct 2004, at 6:38 pm, Dare Obasanjo wrote: > > > > > -1 on this Pace. As it is the values of the rel > > attribute do not have uniform semantics so there is no > > way for a client to consume a link element with a rel > > value it doesn't understand and have it do anything > > reasonable with it. > > > > This Pace basically looks like a way to create an > > extension mechanism that duplicates the ability to use > > extension elements. This redundancy alone is worth the > > -1. > > > > ===== > > THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 > > I will keep a special cache of low-tech weapons and train my troops in > > their use. That way -- even if the heroes manage to neutralize my > > power generator and/or render the standard-issue energy weapons > > useless -- my troops will not be overrun by a handful of savages armed > > with spears and rocks. > > > > > > > > _______________________________ > > Do you Yahoo!? > > Declare Yourself - Register online to vote today! > > http://vote.yahoo.com > > > > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:43:28 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 OAA20815 for ; Fri, 8 Oct 2004 14:43:27 -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 i98IaLIO061613; Fri, 8 Oct 2004 11:36: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 i98IaLVL061612; Fri, 8 Oct 2004 11:36:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IaKIA061606 for ; Fri, 8 Oct 2004 11:36:20 -0700 (PDT) (envelope-from bob@wyman.us) Received: from BobT41 (ppp-63-194-185-131.ded.pacbell.net [63.194.185.131]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id i98IaO9q001858; Fri, 8 Oct 2004 14:36:28 -0400 Message-Id: <200410081836.i98IaO9q001858@ylpvm43.prodigy.net> From: "Bob Wyman" To: "'Dare Obasanjo'" , "'Bjoern Hoehrmann'" Cc: Subject: RE: PaceReformedContent3 Date: Fri, 8 Oct 2004 14:36:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041005173337.90760.qmail@web41213.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSrEHvqGZNmYu9bQielstnkZ+0fOwCVBV+A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: >*sigh* Go read http://www.w3.org/TR/2004/WD-WCAG20-20040730/ These accessibility guidelines say: "Guideline 1.1 Provide text alternatives for all non-text content." However, my personal opinion is that these guidelines are terribly flawed and incomplete. If we had a sincere interest in addressing accessibility needs, we would have another guideline that said: Guideline 1.x Provide non-text alternatives for all text content. The problem is, of course, that text is not the best format for addressing the needs of many of the people whose interests are supposedly addressed by the accessibility guidelines. Forcing everything to text makes sense to those of us who have well working ears, eyes, etc. But, it is less than optimal for those who don't. If there was more non-text content available on the web it would be more likely that we'd have folk investing in devices and methods for generating non-visual or non-aural representations of data for those who have accessibility issues. bob wyman From owner-atom-syntax@mail.imc.org Fri Oct 8 14:51: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 OAA22204 for ; Fri, 8 Oct 2004 14:51: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 i98IgbAf062018; Fri, 8 Oct 2004 11:42:37 -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 i98Igb5a062017; Fri, 8 Oct 2004 11:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98Iga3e062009 for ; Fri, 8 Oct 2004 11:42:37 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i98Ig7lI003773 for ; Fri, 8 Oct 2004 19:42:08 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1f2ed5cd0410081135d7137c9@mail.gmail.com> References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <1f2ed5cd0410081135d7137c9@mail.gmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-842128099; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: PaceLinkRelMechanism Date: Fri, 8 Oct 2004 19:42:07 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4-842128099 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit If we end up going with it people will key off the QNames. I've just read the proposal properly and noticed it reuses the same prefixes as the XML namespaces. Yuck. Whoever wrote this crap needs to read up on abstraction and separation between processing layers. Graham On 8 Oct 2004, at 7:35 pm, Danny Ayers wrote: > Implement what? > > Tools that only use the core definitions would check the value of any > rel attribute against the rel list, exactly as they would have to in > current circumstances. The only real difference would be the absence > of an error message in a validator that checked the enuration. > > On the other hand, if you want to use the link element to associated > an item with something shall we say like an mp3 file, then it's easily > done. > > Cheers, > Danny. > > > On Fri, 8 Oct 2004 19:20:28 +0100, Graham wrote: >> Big -1 too. No one will implement this. >> >> Graham >> >> >> >> On 8 Oct 2004, at 6:38 pm, Dare Obasanjo wrote: >> >>> >>> -1 on this Pace. As it is the values of the rel >>> attribute do not have uniform semantics so there is no >>> way for a client to consume a link element with a rel >>> value it doesn't understand and have it do anything >>> reasonable with it. >>> >>> This Pace basically looks like a way to create an >>> extension mechanism that duplicates the ability to use >>> extension elements. This redundancy alone is worth the >>> -1. >>> >>> ===== >>> THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 >>> I will keep a special cache of low-tech weapons and train my troops >>> in >>> their use. That way -- even if the heroes manage to neutralize my >>> power generator and/or render the standard-issue energy weapons >>> useless -- my troops will not be overrun by a handful of savages >>> armed >>> with spears and rocks. >>> >>> >>> >>> _______________________________ >>> Do you Yahoo!? >>> Declare Yourself - Register online to vote today! >>> http://vote.yahoo.com >>> >> >> >> > > > -- > > http://dannyayers.com --Apple-Mail-4-842128099 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA4MTg0MjA3WjAjBgkqhkiG9w0BCQQxFgQULzRmMaGAQnHPx6C+2G5p89W9 C8MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAjkMd7N6s4MGZNdbXMvSOqDRw F5kCvQwyrGIlr26thVypVvQtpzLqDiXgFiDcJ+z15u+irW3gd6Gg28AmceD42nDC6cvMnif1/U0N omfNwTLiCJG8vphMqUxQNYrcsvEURHC9D4/HkUHjYokSjvaQhvyWzIrS6wuxe4wLqabLa7Nfblf6 RsbZ8ycTiCGdlMHc0O6HRrG27RRzDUf/7JUHp05mrRh0FaMjR88StlEmN9m9eKHRabKJt1kp16Th zIxif0HpSyC1D3LRIqkmogRwS9Ld0XhQjr9qeMYENpA7c9I54sZO9m2cisDvkBbjOl0FcrEy1uK/ KYDjp/7OHCv1EQAAAAAAAA== --Apple-Mail-4-842128099-- From owner-atom-syntax@mail.imc.org Fri Oct 8 14:55:50 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 OAA22780 for ; Fri, 8 Oct 2004 14:55:49 -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 i98ImoCJ063207; Fri, 8 Oct 2004 11:48: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 i98ImoXs063206; Fri, 8 Oct 2004 11:48:50 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98ImngO063196 for ; Fri, 8 Oct 2004 11:48:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so48874rnk for ; Fri, 08 Oct 2004 11:48:30 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr365280rnf; Fri, 08 Oct 2004 11:48:30 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:48:30 -0700 (PDT) Message-ID: <1f2ed5cd04100811481424b25e@mail.gmail.com> Date: Fri, 8 Oct 2004 20:48:30 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceLinkPurpose Cc: atom-syntax@imc.org In-Reply-To: <20041008183306.94827.qmail@web41205.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04100811144da542b2@mail.gmail.com> <20041008183306.94827.qmail@web41205.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I don't see where you get your other extreme from. How > can *anything* be presented as a clickable link? > Please give examples. What is presented could be a labelled hyperlink, System.Windows.Forms.Button, image or whatever. The actions could be, for some value of 'rel': start, next, prev, comments, alternate, source, via, in-reply-to - opens the href URI in a browser window versions, trackback, - opens the feed of versions, trackbacks in an aggregator transform.input, transform.output - apply the XSLT, display in browser icon, logo - display the icon/logo service.post, service.edit - open an editor pre-loaded with verb & target URI details service.feed - open the feed in an aggregator > > But if the definition can be made more useful, then > > I'd back this > > Pace, though would hope that the (controlled) > > extensibility point > > offered by 'rel' wasn't lost in the process. > > Define more useful. Offering classification of the rel values that could help with implementation. As it is PaceLinkPurpose turns the > most ambiguous and poorly designed aspect of Atom into > a well-defined, consistent and usable extensibility > point. How would you improve it? How about making it unambiguous and extensible? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 14:59:07 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 OAA23586 for ; Fri, 8 Oct 2004 14:59: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 i98IomKT063545; Fri, 8 Oct 2004 11:50: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 i98Iomwa063544; Fri, 8 Oct 2004 11:50:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IomjN063531 for ; Fri, 8 Oct 2004 11:50: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 (rwcrmhc13) with SMTP id <20041008185045015003b4ahe>; Fri, 8 Oct 2004 18:50:45 +0000 Date: Fri, 8 Oct 2004 12:50:44 -0600 Subject: Re: PaceLinkRelMechanism 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: <1f2ed5cd0410081105374f5fbb@mail.gmail.com> Message-Id: 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 Friday, October 8, 2004, at 12:05 PM, Danny Ayers wrote: > +1 to the Pace. > > As one of the original proponents of this Pace, I stand by the > original aim - to provide some form of extensibility that has tighter > constraints than 'anything in another namespace can go anywhere'. I > haven't seen any other proposals that offer this in a better form. > -1. I'd prefer a method where the @rel value is entirely self contained, rather than referring to a namespace or schema whose prefix is associated with its URI (or whatever) elsewhere in the document. To avoid potential collisions, making it self contained would require one of: a) the use of URIs in @rel, b) registration of all @rel values or 3) my preference[1]: registration of a prefix, but not of every value (similar to MIME's prs and vnd subtypes). If this idea is not quickly trounced, I'll write a proposal. [1] http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- #5 From owner-atom-syntax@mail.imc.org Fri Oct 8 15:05: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 PAA24240 for ; Fri, 8 Oct 2004 15:04:59 -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 i98IuK4q063947; Fri, 8 Oct 2004 11:56: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 i98IuK8x063946; Fri, 8 Oct 2004 11:56:20 -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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98IuJes063909 for ; Fri, 8 Oct 2004 11:56:20 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so49323rnk for ; Fri, 08 Oct 2004 11:56:18 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr371085rnf; Fri, 08 Oct 2004 11:56:18 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 11:56:18 -0700 (PDT) Message-ID: <1f2ed5cd04100811564ecb0089@mail.gmail.com> Date: Fri, 8 Oct 2004 20:56:18 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceLinkRelMechanism Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <1f2ed5cd0410081135d7137c9@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 8 Oct 2004 19:42:07 +0100, Graham wrote: > If we end up going with it people will key off the QNames. > > I've just read the proposal properly and noticed it reuses the same > prefixes as the XML namespaces. Yuck. You will then have noticed Norm's remark - "The announcement that the next version of HTML is going to use QNames in rel puts this question to bed, I think. Using anything else in Atom would be hard to defend." I am aware this may be a bone of contention, which is why I suggested a possible future amendment to the proposal (to use full URIs) in my previous post. Whoever wrote this crap needs to > read up on abstraction and separation between processing layers. Perhaps you should read up on WG etiquette. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 15:10:33 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 PAA25465 for ; Fri, 8 Oct 2004 15:10:32 -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 i98J3GPH067116; Fri, 8 Oct 2004 12:03: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 i98J3GAN067115; Fri, 8 Oct 2004 12:03:16 -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 i98J3G8V067107 for ; Fri, 8 Oct 2004 12:03: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 (rwcrmhc12) with SMTP id <2004100819031501400rr7oie>; Fri, 8 Oct 2004 19:03:15 +0000 Date: Fri, 8 Oct 2004 13:03:13 -0600 Subject: Re: PaceLinkPurpose 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: <1f2ed5cd04100811144da542b2@mail.gmail.com> Message-Id: 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 Friday, October 8, 2004, at 12:14 PM, Danny Ayers wrote: > +0. > > I like the idea of tightening the semantics, but "logically be > presented to the user as clickable links" doesn't help much. At one > extreme only GETtable hyperlinks fit the bill, That's basically what I was getting at, as suggested by the proposed spec text. (BTW, "logically be presented to the user as clickable links" is not proposed spec text, so ultimately, if that's not a good way to express the idea, it doesn't matter much). > But if the definition can be made more useful, then I'd back this > Pace, though would hope that the (controlled) extensibility point > offered by 'rel' wasn't lost in the process. Here's the proposed spec text that defines the semantics: A Link construct specifies a hyperlink primarily intended to be activated through explicit user interactions such as clicking, selecting a menu item, drag and drop, etc. When accessing the resource pointed to by the href attribute using HTTP, the GET method MUST be used. From owner-atom-syntax@mail.imc.org Fri Oct 8 15:11: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 PAA25615 for ; Fri, 8 Oct 2004 15:11: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 i98J4M5n067171; Fri, 8 Oct 2004 12:04:22 -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 i98J4MMO067170; Fri, 8 Oct 2004 12:04:22 -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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98J4LeI067161 for ; Fri, 8 Oct 2004 12:04:21 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so49960rnk for ; Fri, 08 Oct 2004 12:04:22 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr375716rnh; Fri, 08 Oct 2004 12:04:22 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 12:04:22 -0700 (PDT) Message-ID: <1f2ed5cd041008120420a2f7b6@mail.gmail.com> Date: Fri, 8 Oct 2004 21:04:22 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceLinkParent Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +0 ...and yet more evidence that an extensible relationship operator is needed. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 15:11:50 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 PAA25669 for ; Fri, 8 Oct 2004 15:11:49 -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 i98J03Ev066776; Fri, 8 Oct 2004 12:00:03 -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 i98J033T066775; Fri, 8 Oct 2004 12:00:03 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98J02EP066754 for ; Fri, 8 Oct 2004 12:00:03 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so49616rnk for ; Fri, 08 Oct 2004 12:00:00 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr374139rnh; Fri, 08 Oct 2004 12:00:00 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 12:00:00 -0700 (PDT) Message-ID: <1f2ed5cd041008120057787e0b@mail.gmail.com> Date: Fri, 8 Oct 2004 21:00:00 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceLinkPurpose Cc: Atom Syntax In-Reply-To: <117C86EB-1958-11D9-8095-000A2797ECDA@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008174533.98452.qmail@web41215.mail.yahoo.com> <117C86EB-1958-11D9-8095-000A2797ECDA@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 8 Oct 2004 19:30:01 +0100, Graham wrote: > I like it but don't think it goes far enough, or that its wording is > viable (clicakable/not-clickable is not a valid axis). There are > basically 4 types of link: > > alternate - special case > related - related, via, etc > service > image - favicons and logos Yep, that's more like it. > We already have a special element for service (don't we?). The next > step is to break out all the other types and drop the generic > element completely. I agree with the former suggestion, but dropping link as an extension point would be a step backwards. Cheers, Danny. From owner-atom-syntax@mail.imc.org Fri Oct 8 15:16:57 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 PAA26280 for ; Fri, 8 Oct 2004 15:16:56 -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 i98J9BOD067566; Fri, 8 Oct 2004 12:09:11 -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 i98J9Bt2067565; Fri, 8 Oct 2004 12:09:11 -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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98J9AoU067550 for ; Fri, 8 Oct 2004 12:09:11 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so90328rnl for ; Fri, 08 Oct 2004 12:08:54 -0700 (PDT) Received: by 10.38.126.38 with SMTP id y38mr339537rnc; Fri, 08 Oct 2004 12:08:54 -0700 (PDT) Received: by 10.38.65.11 with HTTP; Fri, 8 Oct 2004 12:08:54 -0700 (PDT) Message-ID: <14be96d304100812081b281463@mail.gmail.com> Date: Fri, 8 Oct 2004 15:08:54 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Bob Wyman Subject: Re: PaceReformedContent3 Cc: atom-syntax@imc.org In-Reply-To: <200410081836.i98IaO9q001858@ylpvm43.prodigy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041005173337.90760.qmail@web41213.mail.yahoo.com> <200410081836.i98IaO9q001858@ylpvm43.prodigy.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 8 Oct 2004 14:36:03 -0400, Bob Wyman wrote: > > Dare Obasanjo wrote: > >*sigh* Go read http://www.w3.org/TR/2004/WD-WCAG20-20040730/ > These accessibility guidelines say: "Guideline 1.1 Provide text > alternatives for all non-text content." However, my personal opinion is that > these guidelines are terribly flawed and incomplete That is well outside our charter. If you are interested in suggesting improvements to the accessibility guidelines, I suggest you join the WAI and/or participate in their public mailing list. > If we had a sincere > interest in addressing accessibility needs, we would have another guideline > that said: > > Guideline 1.x Provide non-text alternatives for all text content. You mean like http://www.w3.org/TR/WCAG10-CORE-TECHS/#multimedia-equivalents ? > The problem is, of course, that text is not the best format for > addressing the needs of many of the people whose interests are supposedly > addressed by the accessibility guidelines. Please tell me how http://www.idlewords.com/audio/manifesto.mp3 can be made more accessible to deaf people than http://www.idlewords.com/audio-manifesto.txt > Forcing everything to text makes > sense to those of us who have well working ears, eyes, etc. But, it is less > than optimal for those who don't. This makes no sense at all. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri Oct 8 15:18: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 PAA26501 for ; Fri, 8 Oct 2004 15:18: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 i98JC6rO067872; Fri, 8 Oct 2004 12:12: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 i98JC6L3067871; Fri, 8 Oct 2004 12:12:06 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JC5DB067864 for ; Fri, 8 Oct 2004 12:12:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so50377rnk for ; Fri, 08 Oct 2004 12:11:29 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr378442rnh; Fri, 08 Oct 2004 12:11:29 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 12:11:29 -0700 (PDT) Message-ID: <1f2ed5cd041008121114cd2e68@mail.gmail.com> Date: Fri, 8 Oct 2004 21:11:29 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceLinkTitle Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +0 I think this should be considered in the context of the structural semantics of the format and any conventions derived from their definition. At the moment there's isn't much in the way of systematic definition (e.g. that a child element applies to its immediate parent), it's all very term-by-term, with a hint of visual consistency thrown in for good measure... -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 15:19: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 PAA26535 for ; Fri, 8 Oct 2004 15:18:59 -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 i98JB5np067810; Fri, 8 Oct 2004 12:11:05 -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 i98JB55D067809; Fri, 8 Oct 2004 12:11:05 -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 i98JB5TF067781 for ; Fri, 8 Oct 2004 12:11:05 -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 <2004100819110301600c5fqde>; Fri, 8 Oct 2004 19:11:03 +0000 Date: Fri, 8 Oct 2004 13:10:56 -0600 Subject: Re: PaceLinkPurpose 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: <117C86EB-1958-11D9-8095-000A2797ECDA@mac.com> Message-Id: 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 Friday, October 8, 2004, at 12:30 PM, Graham wrote: > There are basically 4 types of link: > > alternate - special case > related - related, via, etc I see "alternate" as a "related" type, though I'd agree it's possible to make a distinction. I'm just not sure it's terribly useful to do so. > service Yes, we already have a separate element. > image - favicons and logos These haven't made it into the link element yet, though they've appeared in proposals. From owner-atom-syntax@mail.imc.org Fri Oct 8 15:19:24 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 PAA26596 for ; Fri, 8 Oct 2004 15:19:24 -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 i98JCPaH067902; Fri, 8 Oct 2004 12:12:25 -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 i98JCPQ2067901; Fri, 8 Oct 2004 12:12:25 -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 i98JCO54067892 for ; Fri, 8 Oct 2004 12:12:25 -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 <2004100819122301600c05lve>; Fri, 8 Oct 2004 19:12:23 +0000 Date: Fri, 8 Oct 2004 13:12:22 -0600 Subject: Re: PaceLinkAttrDefaults 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: <1f2ed5cd04100811234922ea3e@mail.gmail.com> Message-Id: 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 Friday, October 8, 2004, at 12:23 PM, Danny Ayers wrote: > -1. I'm also -1. +1 to adding @rel="related" (which is covered by PaceLinkDelicious), but -1 to only two @rel values, and -1 to "alternate" being a default. The problem I have with that is that the ability to have a link with no @rel could lead to people using link sans @rel for all sorts of links. If @rel is required, people will be more likely to choose the right value for it. From owner-atom-syntax@mail.imc.org Fri Oct 8 15:24: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 PAA27292 for ; Fri, 8 Oct 2004 15:24:05 -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 i98JHD4N068340; Fri, 8 Oct 2004 12:17: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 i98JHD1J068339; Fri, 8 Oct 2004 12:17: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JHCxe068331 for ; Fri, 8 Oct 2004 12:17:13 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so50711rnk for ; Fri, 08 Oct 2004 12:17:11 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr380192rnh; Fri, 08 Oct 2004 12:17:11 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 12:17:11 -0700 (PDT) Message-ID: <1f2ed5cd0410081217ed68986@mail.gmail.com> Date: Fri, 8 Oct 2004 21:17:11 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceReplaceLinkElement Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 Slightly guarded - I'm not so sure of the detail of the suggested syntax, e.g. something like might be better expressed as and I do reckon there's a role for as an extension point, specifically for link-like relationships. But generally, tidying up is long overdue. Cheers, Danny -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 15:25:19 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 PAA27440 for ; Fri, 8 Oct 2004 15:25:19 -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 i98JFYHe068249; Fri, 8 Oct 2004 12:15: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 i98JFYuQ068248; Fri, 8 Oct 2004 12:15:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JFYai068242 for ; Fri, 8 Oct 2004 12:15:34 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-7470.lns3-c7.dsl.pol.co.uk ([84.65.221.46] helo=[192.168.0.2]) by cmailg3.svr.pol.co.uk with esmtp (Exim 4.14) id 1CG0DJ-0001cu-4r for atom-syntax@imc.org; Fri, 08 Oct 2004 20:15:37 +0100 Message-ID: <4166E799.9010102@isofarro.uklinux.net> Date: Fri, 08 Oct 2004 20:16:41 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceReformedContent3 References: <200410081836.i98IaO9q001858@ylpvm43.prodigy.net> In-Reply-To: <200410081836.i98IaO9q001858@ylpvm43.prodigy.net> 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 Bob Wyman wrote: > If we had a sincere interest in addressing > accessibility needs, we would have another guideline that > said: > > Guideline 1.x Provide non-text alternatives for all text > content. Checkpoint 14.2 [1] > The problem is, of course, that text is not the best format > for addressing the needs of many of the people whose > interests are supposedly addressed by the accessibility > guidelines. Textual equivalents to non-textual media benefits a large section of disabled people - notably blind visitors and partially sighted visitors. Yes, people suffering from dyslexia and other comprehension/related related disabilities would prefer an image based approach - for example peepo [2] > If there was more non-text content available on the web it > would be more likely that we'd have folk investing in devices > and methods for generating non-visual or non-aural > representations of data for those who have accessibility > issues. Speech recognition is improving and slowly getting there - mainly due to IBM investing heavily into ViaVoice. Are images -> text or images -> sound even realistically possible? Let alone the context issues. Mike. [1] http://www.w3.org/TR/WCAG10/#gl-facilitate-comprehension [2] http://www.peepo.com/ From owner-atom-syntax@mail.imc.org Fri Oct 8 15:26:40 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 PAA27563 for ; Fri, 8 Oct 2004 15:26: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 i98JJr2W068625; Fri, 8 Oct 2004 12:19: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 i98JJr9m068624; Fri, 8 Oct 2004 12:19:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JJr55068614 for ; Fri, 8 Oct 2004 12:19:53 -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 (sccrmhc12) with SMTP id <200410081919510120037pepe>; Fri, 8 Oct 2004 19:19:51 +0000 Date: Fri, 8 Oct 2004 13:19:48 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceLinkTitle From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <054DE353-195F-11D9-BE35-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 +1 on the idea, but a few adjustments are needed. The title should be a "Text Construct" though, now that PaceReformedContent3 has been accepted. The proposed text doesn't specify whether the title is required. It should be optional (it's not needed, for example, for "start", "prev" and "next" links). From owner-atom-syntax@mail.imc.org Fri Oct 8 15:27:40 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 PAA27664 for ; Fri, 8 Oct 2004 15:27:39 -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 i98JGWF1068303; Fri, 8 Oct 2004 12:16: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 i98JGW6x068302; Fri, 8 Oct 2004 12:16:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JGVQ5068293 for ; Fri, 8 Oct 2004 12:16:31 -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 (sccrmhc12) with SMTP id <200410081916300120039ueie>; Fri, 8 Oct 2004 19:16:30 +0000 Date: Fri, 8 Oct 2004 13:16:28 -0600 Subject: Re: PaceLinkConstruct 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: <1f2ed5cd04100811265a63a364@mail.gmail.com> Message-Id: <8E08D7E1-195E-11D9-BE35-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 Friday, October 8, 2004, at 12:26 PM, Danny Ayers wrote: > -1 > > Again in the current context. This excessively overloads the syntax in > terms of core functionality while losing the benefit of a controlled > extension axis. > I'm +1 on this, with the possible exception of @rev. None of the proposed values (given that the service.* values have been removed from link by PaceServiceElement, so can be removed from this proposal) seem to cause problems with the syntax to me. I'm undecided about whether to be for @rev, or to prefer using just @rel. Were we to stick with just @rel, we'd have a collision between @rel="comment" and @rev="comment". The latter might be replaced by "@rel="in-reply-to" (PaceLinkParent) or something similar. @rev="update", whether it ends up in @rev or @rel might be better as "updates" (which would parallel "replaces" better). From owner-atom-syntax@mail.imc.org Fri Oct 8 15:28: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 PAA27743 for ; Fri, 8 Oct 2004 15:28:41 -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 i98JLvcn068782; Fri, 8 Oct 2004 12:21: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 i98JLvOJ068781; Fri, 8 Oct 2004 12:21:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98JLvBZ068765 for ; Fri, 8 Oct 2004 12:21:57 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041008192156.86688.qmail@web41206.mail.yahoo.com> Received: from [67.160.45.9] by web41206.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 12:21:56 PDT Date: Fri, 8 Oct 2004 12:21:56 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkRelMechanism To: Danny Ayers , Graham Cc: Atom Syntax In-Reply-To: <1f2ed5cd04100811564ecb0089@mail.gmail.com> 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: --- Danny Ayers wrote: > > You will then have noticed Norm's remark - "The > announcement that the > next version of HTML is going to use QNames in rel > puts this question > to bed, I think. Using anything else in Atom would > be hard to defend." Having QNames in content causes a ridiculous amount of problems in XML processing. It's unfortunate that we are stuck with them in core XML technologies like XSLT and W3C XML Schema but it doesn't mean this should be allowed to spread unchecked in the XML world. Even the W3C TAG frowns on the practice but admits the cat is already out of the bag http://www.w3.org/2001/tag/doc/qnameids.html ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 8 15: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 PAA27766 for ; Fri, 8 Oct 2004 15:28:46 -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 i98JLsur068773; Fri, 8 Oct 2004 12:21:54 -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 i98JLse5068772; Fri, 8 Oct 2004 12:21:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JLrE4068761 for ; Fri, 8 Oct 2004 12:21:53 -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 (sccrmhc11) with SMTP id <2004100819215101100jtubhe>; Fri, 8 Oct 2004 19:21:52 +0000 Date: Fri, 8 Oct 2004 13:21:50 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDateOfSubject From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <4DD414D5-195F-11D9-BE35-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 -1. Let's leave this to an extension covering the issue more comprehensively. From owner-atom-syntax@mail.imc.org Fri Oct 8 15:42:43 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 PAA29135 for ; Fri, 8 Oct 2004 15:42:42 -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 i98JWTmE069433; Fri, 8 Oct 2004 12:32:29 -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 i98JWTi6069432; Fri, 8 Oct 2004 12:32:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JWSNa069424 for ; Fri, 8 Oct 2004 12:32:28 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28054; Fri, 8 Oct 2004 15:32:30 -0400 (EDT) Message-Id: <200410081932.PAA28054@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-protocol-02.txt Date: Fri, 08 Oct 2004 15:32:30 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Publishing Protocol Author(s) : J. Gregorio, R. Sayre Filename : draft-ietf-atompub-protocol-02.txt Pages : 22 Date : 2004-10-8 This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (draft-ietf-atompub-format-02.txt). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-8155941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8155941.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Fri Oct 8 15:45:04 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 PAA29530 for ; Fri, 8 Oct 2004 15:45: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 i98JZPGw069757; Fri, 8 Oct 2004 12:35:25 -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 i98JZPZg069756; Fri, 8 Oct 2004 12:35:25 -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 i98JZPUQ069747 for ; Fri, 8 Oct 2004 12:35:25 -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 <2004100819352301300c2gp3e>; Fri, 8 Oct 2004 19:35:24 +0000 Date: Fri, 8 Oct 2004 13:35:22 -0600 Subject: Re: PaceLinkPurpose 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: <1f2ed5cd04100811481424b25e@mail.gmail.com> Message-Id: <31AD9587-1961-11D9-BE35-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 Friday, October 8, 2004, at 12:48 PM, Danny Ayers wrote: > The actions could be, for some value of 'rel': > > start, next, prev, comments, alternate, source, via, in-reply-to - > opens the href URI in a browser window > > versions, trackback, - opens the feed of versions, trackbacks in an > aggregator So we have "opens in a browser" and "opens in an aggregator". Not so different from clicking a link to a PDF on the web today. It may open in a browser window or launch Acrobat's UI. Same for various audio and video types, etc. I don't think what it opens in really matters. Nothing below here is a valid @rel value in the current spec, as it is scheduled to be amended based on proposals that have been accepted. (And I don't think any of them belong in ). > transform.input, transform.output - apply the XSLT, display in browser > > icon, logo - display the icon/logo > > service.post, service.edit - open an editor pre-loaded with verb & > target URI details > > service.feed - open the feed in an aggregator From owner-atom-syntax@mail.imc.org Fri Oct 8 15:48:50 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 PAA00122 for ; Fri, 8 Oct 2004 15:48:48 -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 i98Jf9Uo070128; Fri, 8 Oct 2004 12:41:09 -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 i98Jf98r070127; Fri, 8 Oct 2004 12:41:09 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98Jf8bp070120 for ; Fri, 8 Oct 2004 12:41:08 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so52127rnk for ; Fri, 08 Oct 2004 12:40:21 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr388568rnh; Fri, 08 Oct 2004 12:40:21 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 12:40:21 -0700 (PDT) Message-ID: <1f2ed5cd041008124070c6a517@mail.gmail.com> Date: Fri, 8 Oct 2004 21:40:21 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceReformedContent3 Cc: mint@franklinmint.fm, Graham , Bjoern Hoehrmann , atom-syntax@imc.org In-Reply-To: <20041005185949.48332.qmail@web41212.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4162ED88.7050300@franklinmint.fm> <20041005185949.48332.qmail@web41212.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 5 Oct 2004 11:59:49 -0700 (PDT), Dare Obasanjo wrote: [sorry to butt in, but this is irresistible] > > > > url="http://homepage.mac.com/adamcurry/DSC/DSC-2004-10-05.mp3" > > > > length="34110194" type="audio/mpeg"/> > > > > This feed highlights the problem exactly. This feed is > useless to every aggregator that doesn't support > enclosures. On the other hand if there was a > element that described the audio file > then linked to it this content would accessible to a > larger number of aggregators. > > The Channel 9 folks[0] used to have feeds with > enclosures and no descriptions but realized they were > shutting out a number of aggregators so began to have > both and elements. What you are talking about there is essentially partial understanding. Some might call that pixie dust. If it was done in a more systematic fashion, who knows what magic might result. Cheers, Danny. > [0] http://channel9.msdn.com -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 15:58: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 PAA01855 for ; Fri, 8 Oct 2004 15:58: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 i98JoZ3s070878; Fri, 8 Oct 2004 12:50:35 -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 i98JoZw3070877; Fri, 8 Oct 2004 12:50:35 -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 i98JoZdp070866 for ; Fri, 8 Oct 2004 12:50:35 -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 1CG0l7-0006fL-0f; Fri, 08 Oct 2004 19:50:33 +0000 Message-ID: <4166EF86.7030408@franklinmint.fm> Date: Fri, 08 Oct 2004 15:50:30 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy , Atom Syntax Subject: Re: PaceLinkTitle References: <054DE353-195F-11D9-BE35-003065EA6144@geckotribe.com> In-Reply-To: <054DE353-195F-11D9-BE35-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > +1 on the idea, but a few adjustments are needed. The title should be a > "Text Construct" though, now that PaceReformedContent3 has been > accepted. The proposed text doesn't specify whether the title is > required. It should be optional (it's not needed, for example, for > "start", "prev" and "next" links). -1 on the idea. Use an "Accept-Language" header to get the best language in the first place, and reference entries in alternate languages by linking. This is overkill, and kind of useless in the absence of multiple content elements. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 8 16:01:40 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 QAA02508 for ; Fri, 8 Oct 2004 16:01:39 -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 i98JreMe071224; Fri, 8 Oct 2004 12:53: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 i98JreUb071223; Fri, 8 Oct 2004 12:53:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98Jrd23071216 for ; Fri, 8 Oct 2004 12:53:39 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i98Jrhui019732 for ; Fri, 8 Oct 2004 13:53:43 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5A003BG79JDN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 08 Oct 2004 13:53:43 -0600 (MDT) Received: from [192.168.1.27] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5A00LYI79IT4@mail.sun.net> for atom-syntax@imc.org; Fri, 08 Oct 2004 13:53:43 -0600 (MDT) Date: Fri, 08 Oct 2004 12:53:57 -0700 From: Tim Bray Subject: Atom WG sociology To: Atom WG Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 7, 2004, at 11:13 AM, Dan Brickley wrote: > Regarding 'debating style', there's imho no need for this snipey style > of > interaction here. Perhaps you and Eric and Mark know each other very > well > and there's an implicit, friendly smile behind this exchange, but for > those folks who aren't in the loop, such talk can sour the atmosphere > and discourage participation. +1. And drop the hypotheticals, it already has driven more than one person away from Atom. It also deters people who have new ideas from offering them because they worry (justifiably) that they will be subject to highschool-playground style abuse. I wish I knew how to stop it. Paul and I have on multiple occasions leaned on people off-list who've been behaving inappropriately, and typically they tend to behave a little bit better for two or three weeks and then revert to childishness. So we think that's probably not an effective way to approach the problem. That leaves us with public advocacy, i.e. what we're doing here. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 8 16:27:50 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 QAA05970 for ; Fri, 8 Oct 2004 16:27:49 -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 i98KJ2Sw072705; Fri, 8 Oct 2004 13:19: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 i98KJ2Ts072704; Fri, 8 Oct 2004 13:19:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98KJ1e7072697 for ; Fri, 8 Oct 2004 13:19:01 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i98KJ5ui002256 for ; Fri, 8 Oct 2004 14:19:05 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5A002QT8FT6A@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 08 Oct 2004 14:19:06 -0600 (MDT) Received: from [192.168.1.27] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5A00L6Z8FST4@mail.sun.net> for atom-syntax@imc.org; Fri, 08 Oct 2004 14:19:05 -0600 (MDT) Date: Fri, 08 Oct 2004 13:19:19 -0700 From: Tim Bray Subject: Re: PaceReformedContent3 In-reply-to: <4166B4D2.1080502@franklinmint.fm> To: mint@franklinmint.fm Cc: Mark Pilgrim , "janne.jalkanen@nokia.com" , atom-syntax@imc.org Message-id: <55BB6FA4-1967-11D9-9411-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> <4166B4D2.1080502@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 8, 2004, at 8:40 AM, Robert Sayre wrote: > I know we have a constraint. I question whether the constraint helps > accessibility. > > > ... > My First Program > <img src="my_thumbnail.jpg"> > > You can't legislate against stupidity or perversity. To quote Mark [http://imc.org/atom-syntax/mail-archive/msg10365.html]: "If individual authors choose to publish inaccessible content, that is an education/advocacy problem. If individual authors are unable to publish accessible content, that is a specification problem." I think the rules around atom:summary give us a good accessibility story. If you or MarkP wanted to propose some language to improve the advocacy in the spec, that would be fine. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 8 16:48:19 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 QAA10889 for ; Fri, 8 Oct 2004 16:48: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 i98KeRrY074134; Fri, 8 Oct 2004 13:40:27 -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 i98KeRul074133; Fri, 8 Oct 2004 13:40:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98KeQc8074127 for ; Fri, 8 Oct 2004 13:40:26 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i98KeUNH006344 for ; Fri, 8 Oct 2004 14:40:30 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5A001539FIP0@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 08 Oct 2004 14:40:30 -0600 (MDT) Received: from [192.168.1.27] ([204.174.35.171]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5A00FF99FH7M@mail.sun.net> for atom-syntax@imc.org; Fri, 08 Oct 2004 14:40:30 -0600 (MDT) Date: Fri, 08 Oct 2004 13:40:44 -0700 From: Tim Bray Subject: Re: PaceLinkRelMechanism In-reply-to: <1f2ed5cd04100811564ecb0089@mail.gmail.com> To: Atom Syntax Message-id: <537A8721-196A-11D9-9411-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <1f2ed5cd0410081135d7137c9@mail.gmail.com> <1f2ed5cd04100811564ecb0089@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 8, 2004, at 11:56 AM, Danny Ayers wrote: > You will then have noticed Norm's remark - "The announcement that the > next version of HTML is going to use QNames in rel puts this question > to bed, I think. Using anything else in Atom would be hard to defend." Without taking any position on the underlying issue, but noting with pleasure the lively debate, I'd like to say that as far as I'm concerned, what the designers of the in-progress, unstable, violently-controversial next version of HTML are deciding to do is of approximately zero significance to our design decisions for Atom. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 8 16:52: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 QAA12170 for ; Fri, 8 Oct 2004 16:52:29 -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 i98Ki3a1074415; Fri, 8 Oct 2004 13:44:03 -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 i98Ki3PV074414; Fri, 8 Oct 2004 13:44:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98Ki39T074407 for ; Fri, 8 Oct 2004 13:44:03 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i98Ki7NH007947 for ; Fri, 8 Oct 2004 14:44:07 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5A003OA9LIDN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 08 Oct 2004 14:44:07 -0600 (MDT) Received: from [192.168.1.27] ([204.174.35.171]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5A00FGK9LI84@mail.sun.net> for atom-syntax@imc.org; Fri, 08 Oct 2004 14:44:06 -0600 (MDT) Date: Fri, 08 Oct 2004 13:44:20 -0700 From: Tim Bray Subject: Re: PaceLinkRelMechanism In-reply-to: <20041008192156.86688.qmail@web41206.mail.yahoo.com> To: Dare Obasanjo Cc: Graham , Atom Syntax , Danny Ayers Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041008192156.86688.qmail@web41206.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 8, 2004, at 12:21 PM, Dare Obasanjo wrote: > Having QNames in content causes a ridiculous amount of > problems in XML processing. It's unfortunate that we > are stuck with them in core XML technologies like XSLT > and W3C XML Schema but it doesn't mean this should be > allowed to spread unchecked in the XML world. +1 -Tim From owner-atom-syntax@mail.imc.org Fri Oct 8 18:23:43 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 SAA24997 for ; Fri, 8 Oct 2004 18:23:42 -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 i98MBZlH082728; Fri, 8 Oct 2004 15:11:35 -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 i98MBZQG082727; Fri, 8 Oct 2004 15:11:35 -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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98MBYqV082721 for ; Fri, 8 Oct 2004 15:11:34 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so59500rnk for ; Fri, 08 Oct 2004 15:11:30 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr435280rnh; Fri, 08 Oct 2004 15:11:30 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 8 Oct 2004 15:11:30 -0700 (PDT) Message-ID: <1f2ed5cd041008151144f62ec2@mail.gmail.com> Date: Sat, 9 Oct 2004 00:11:30 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: PaceLinkRelMechanism Cc: Atom Syntax In-Reply-To: <537A8721-196A-11D9-9411-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <1f2ed5cd0410081135d7137c9@mail.gmail.com> <1f2ed5cd04100811564ecb0089@mail.gmail.com> <537A8721-196A-11D9-9411-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 08 Oct 2004 13:40:44 -0700, Tim Bray wrote: > > On Oct 8, 2004, at 11:56 AM, Danny Ayers wrote: > > > You will then have noticed Norm's remark - "The announcement that the > > next version of HTML is going to use QNames in rel puts this question > > to bed, I think. Using anything else in Atom would be hard to defend." > > Without taking any position on the underlying issue, but noting with > pleasure the lively debate, I'd like to say that as far as I'm > concerned, what the designers of the in-progress, unstable, > violently-controversial next version of HTML are deciding to do is of > approximately zero significance to our design decisions for Atom. -Tim Please allow me to be contrary. I'll declare my position on the underlying issue - I think QNames in attributes are generally a bad idea. But they are in use in other XML formats, and they may offer a pragmatic solution to some problems. Their use in places like XSLT are of little consequence to Atom. But the next version of HTML is at least a potential format for Atom payloads. I could be missing something, but if the content of an Atom feed is (unescaped) XHTML, and that version of XHTML has QNames in attributes then it seems to me the document as a whole will have QNames in attributes. The fact that those attributes won't be in the Atom namespace is only half the story, the prefix binding may not be inside the content fragment. Leak, leak. What responsibility should the carrier format have for maintaining the association? As with control characters in plain text, I would suggest that the format of the content probably is of significance to decisions regarding the delivery format. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 8 18:28: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 SAA25156 for ; Fri, 8 Oct 2004 18:28: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 i98MJSNp083199; Fri, 8 Oct 2004 15:19: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 i98MJS7Z083198; Fri, 8 Oct 2004 15:19: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 i98MJRI2083192 for ; Fri, 8 Oct 2004 15:19:28 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CG35F-0005vS-23 for atom-syntax@imc.org; Fri, 08 Oct 2004 22:19:29 +0000 Message-ID: <41671273.8090603@franklinmint.fm> Date: Fri, 08 Oct 2004 18:19:31 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: modifications to PaceSimpleResourcePosting 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 As promised, I've documented the changes Joe and I felt were appropriate. The following was redundant given the definition of the 201 response-- [If the request is successful then the server returns a new unique URI where a representation of the resource may be retrieved. The URI returned MUST be suitable for use in a subsequent HTTP GET and MUST return the resource data originally uploaded. The URI returned MAY also be usable for editing of the resource via PUT and DELETE, or via full WebDAV.] Removed-- [Locating (Note: There is an open discussion regarding the use of @title to distinguish links associated with different feeds; this proposal will follow whatever the consensus is on that point.)] Response contradicts the introduction-- "The returned resource URI SHOULD also support PUT and DELETE." Removed from response code 201-- [The returned resource URI SHOULD also support PUT and DELETE] Method privileges and support are not to be mandated. We can specify how tasks are to be accomplished, but not that they "SHOULD" be. [The server MAY return an ETag or other caching information in the response, and the client and any intermediate proxies MAY use the information returned in this response for normal caching.] We are using HTTP, so this is redundant. Response code 400-- Problems considering draft 01 language, updated to match PostURI Added Response code 415-- Added to account for supported MIME types. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 8 19:11:23 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 TAA27460 for ; Fri, 8 Oct 2004 19:11:22 -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 i98N39NL085404; Fri, 8 Oct 2004 16:03:09 -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 i98N39Gx085403; Fri, 8 Oct 2004 16:03:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98N38qb085394 for ; Fri, 8 Oct 2004 16:03:09 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D95194F0A4 for ; Fri, 8 Oct 2004 19:03:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4166A063.8040906@franklinmint.fm> References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-28-838949317" Message-Id: <5B9A60EE-1952-11D9-B80C-000A95718F82@w3.org> Content-Transfer-Encoding: 7bit From: Karl Dubost Subject: Re: PaceReformedContent3 Date: Fri, 8 Oct 2004 13:49:09 -0400 To: "Atom Syntax'" X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-28-838949317 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 08 oct. 2004, =E0 10:12, Robert Sayre a =E9crit : > Here is a sample entry, which demonstrates a very common use case: > > > ... > A Picture of My Trip To The Lake > > > > How do we improve this? Would including a summary make it better? ... A Picture of My Trip To The Lake Beach and Trees at the Lake This is an accessible constructs. The title is not completely necessary=20= related to your pictures as you may notice here. Because your title is=20= not a description of the picture but the contextual meaning of the=20 picture which is different. Hope it helps to understand. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** --Apple-Mail-28-838949317 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?= content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBZtMW+dmsZnpx3tkRAtfQAJ90HIWTAQn7VUAXxktEmm5Q3oLehwCfQ0x0 B1guj2vKtXPw3ccNphQwSeg= =KrBY -----END PGP SIGNATURE----- --Apple-Mail-28-838949317-- From owner-atom-syntax@mail.imc.org Fri Oct 8 20:42: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 UAA04962 for ; Fri, 8 Oct 2004 20:42:24 -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 i990Z6Ua091639; Fri, 8 Oct 2004 17:35: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 i990Z67U091638; Fri, 8 Oct 2004 17:35:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i990Z5hg091631 for ; Fri, 8 Oct 2004 17:35:05 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 6CE894F39B; Fri, 8 Oct 2004 20:35:09 -0400 (EDT) Message-Id: <6.0.0.20.2.20041009093046.05b36a78@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 09 Oct 2004 09:34:15 +0900 To: Tim Bray , mint@franklinmint.fm From: Martin Duerst Subject: Re: PaceReformedContent3 Cc: Mark Pilgrim , "janne.jalkanen@nokia.com" , atom-syntax@imc.org In-Reply-To: <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> References: <14be96d304100806044f7b4bd2@mail.gmail.com> <4166A063.8040906@franklinmint.fm> <53A90892-193C-11D9-9411-000A95A51C9E@sun.com> Mime-Version: 1.0 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 At 00:11 04/10/09, Tim Bray wrote: >We *have* a constraint: that atom:summary is required in any case where the content is not locally provided or is is not text/* or *xml. Thus, I claim the spec currently meets the bar for accessibility. -Tim I think on first approximation, it does. But looking at the details, it may not be that easy. There are lots of different xml formats. Some of them are trivially accessible, some of the are unaccessible to some people, some are tough to handle for virtually anybody. I think the atom content spec should have a section on accessibility in a similar way it has a section on security issues. [If anybody thinks this is a good idea, please start a Pace. I won't have the time to get around to do it for at least a few weeks (and I don't think I'm an expert, either).] Regards, Martin. From owner-atom-syntax@mail.imc.org Fri Oct 8 20:43: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 UAA05082 for ; Fri, 8 Oct 2004 20:43: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 i990Y3P6091575; Fri, 8 Oct 2004 17:34:03 -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 i990Y39v091573; Fri, 8 Oct 2004 17:34:03 -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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i990Y2MW091557 for ; Fri, 8 Oct 2004 17:34:02 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so91537rnl for ; Fri, 08 Oct 2004 17:33:08 -0700 (PDT) Received: by 10.38.65.39 with SMTP id n39mr481398rna; Fri, 08 Oct 2004 17:33:08 -0700 (PDT) Received: by 10.38.99.80 with HTTP; Fri, 8 Oct 2004 17:33:08 -0700 (PDT) Message-ID: <3f1451f504100817335802f1cd@mail.gmail.com> Date: Fri, 8 Oct 2004 20:33:08 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-02.txt Cc: Atom Protocol In-Reply-To: <200410081932.PAA28054@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410081932.PAA28054@ietf.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As usual Robert and I have made HTML, TXT, and side-by-side color diffs of the -02 version available here: http://bitworking.org/projects/atom/ Thanks, -joe On Fri, 08 Oct 2004 15:32:30 -0400, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : J. Gregorio, R. Sayre > Filename : draft-ietf-atompub-protocol-02.txt > Pages : 22 > Date : 2004-10-8 > > This memo presents a protocol for using XML (Extensible Markup > Language) and HTTP (HyperText Transport Protocol) to edit content. > > The Atom Publishing Protocol is an application-level protocol for > publishing and editing Web resources belonging to periodically > updated websites. The protocol at its core is the HTTP transport of > Atom-formatted representations. The Atom format is documented in the > Atom Syndication Format (draft-ietf-atompub-format-02.txt). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ENCODING mime > FILE /internet-drafts/draft-ietf-atompub-protocol-02.txt > > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Oct 8 22:57:57 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 WAA21993 for ; Fri, 8 Oct 2004 22:57:57 -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 i992kGaL001139; Fri, 8 Oct 2004 19:46: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 i992kGgR001138; Fri, 8 Oct 2004 19:46:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i992kF31001113 for ; Fri, 8 Oct 2004 19:46:16 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 12:45:46 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 12:45:49 +1000 Subject: Re: PaceLinkPurpose From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd041008120057787e0b@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 5:00 AM, "Danny Ayers" wrote: >> alternate - special case >> related - related, via, etc >> service >> image - favicons and logos > > Yep, that's more like it. transform.input, transform.output? links to CSS? links to javascript? (god forbid!) e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:03:55 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 XAA22438 for ; Fri, 8 Oct 2004 23:03:55 -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 i992uK9B003029; Fri, 8 Oct 2004 19:56: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 i992uKNb003028; Fri, 8 Oct 2004 19:56:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i992uIeF003022 for ; Fri, 8 Oct 2004 19:56:19 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 12:56:20 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 12:56:22 +1000 Subject: Re: PaceLinkParent From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd041008120420a2f7b6@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 5:04 AM, "Danny Ayers" wrote: > +0 > > ...and yet more evidence that an extensible relationship operator is needed. and since the URI it requires is atom:id, it quite possibly could be a non-traversable URI like tag:example.com,2004-01-01:/blog/1 -1 since the semantic intended for the URI is one of association, not traversal. e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:07: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 XAA22598 for ; Fri, 8 Oct 2004 23:07: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 i992qfIs001553; Fri, 8 Oct 2004 19:52: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 i992qfpB001552; Fri, 8 Oct 2004 19:52:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i992qead001545 for ; Fri, 8 Oct 2004 19:52:40 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 12:52:42 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 12:52:43 +1000 Subject: Re: PaceLinkPurpose From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 5:03 AM, "Antone Roundy" wrote: [spec text] > A Link construct specifies a hyperlink primarily intended to be > activated through explicit user interactions such as clicking, > selecting a menu item, drag and drop, etc. When accessing the resource > pointed to by the href attribute using HTTP, the GET method MUST be > used. s/activated/traversed/ ? Problem: "GET method MUST be used" disallows the use of HEAD for it's useful reasons. The intent, iirc, was to disallow POST and similar access methods requiring more payload than just the URI. It also disallows PROPFIND and OPTIONS and maybe other methods too, but since I know squat about these I don't know if that is good or bad. e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:10:59 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 XAA22929 for ; Fri, 8 Oct 2004 23:10:58 -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 i9933has003548; Fri, 8 Oct 2004 20:03:43 -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 i9933hFV003547; Fri, 8 Oct 2004 20:03:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9933gpL003539 for ; Fri, 8 Oct 2004 20:03:42 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:03:44 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:03:46 +1000 Subject: Re: PaceReformedContent3 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <14be96d304100812081b281463@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 5:08 AM, "Mark Pilgrim" wrote: > Please tell me how http://www.idlewords.com/audio/manifesto.mp3 can be > made more accessible to deaf people than > http://www.idlewords.com/audio-manifesto.txt http://www.idlewords.com/aslan/manifesto.mov deaf people often prefer visual communication by signing over reading text. e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:16: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 XAA23252 for ; Fri, 8 Oct 2004 23:16:16 -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 i9939OWi004441; Fri, 8 Oct 2004 20:09: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 i9939OWr004440; Fri, 8 Oct 2004 20:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9939MQ4004434 for ; Fri, 8 Oct 2004 20:09:23 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:09:25 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:09:27 +1000 Subject: Re: PaceLinkTitle From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd041008121114cd2e68@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit the pace is lacking examples, but I think the proposal was to allow something like this: Moi! Me! but doesn't xml:lang also apply to element attributes? e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:23: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 XAA23632 for ; Fri, 8 Oct 2004 23:23: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 i993FiJA005271; Fri, 8 Oct 2004 20:15: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 i993FiJj005270; Fri, 8 Oct 2004 20:15:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993Fhea005263 for ; Fri, 8 Oct 2004 20:15:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:15:45 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:15:47 +1000 Subject: Re: PaceReplaceLinkElement From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd0410081217ed68986@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 linking resources is too fundamental to require yet another extension module every time someone wants to express a link with a new relationship. e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:44:43 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 XAA24717 for ; Fri, 8 Oct 2004 23:44:42 -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 i993aGxL006634; Fri, 8 Oct 2004 20:36: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 i993aGJc006633; Fri, 8 Oct 2004 20:36:16 -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 i993aFQm006623 for ; Fri, 8 Oct 2004 20:36:15 -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 <2004100903361601600c1t23e>; Sat, 9 Oct 2004 03:36:16 +0000 Date: Fri, 8 Oct 2004 21:36:15 -0600 Subject: Re: PaceLinkParent 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: Message-Id: <5FCC67EB-19A4-11D9-BE35-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 Friday, October 8, 2004, at 08:56 PM, Eric Scheid wrote: > and since the URI it requires is atom:id, it quite possibly could be a > non-traversable URI like tag:example.com,2004-01-01:/blog/1 > > -1 since the semantic intended for the URI is one of association, not > traversal. > Good point--I hadn't thought of that. Another element would be more appropriate, especially if PaceLinkPurpose is adopted. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:46: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 XAA24838 for ; Fri, 8 Oct 2004 23:46: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 i993awv9006689; Fri, 8 Oct 2004 20:36:58 -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 i993awld006688; Fri, 8 Oct 2004 20:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993avHX006682 for ; Fri, 8 Oct 2004 20:36:57 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:36:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:37:00 +1000 Subject: Re: PaceLinkTitle From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4166EF86.7030408@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 5:50 AM, "Robert Sayre" wrote: > -1 on the idea. Use an "Accept-Language" header to get the best language > in the first place, and reference entries in alternate languages by > linking. This is overkill, and kind of useless in the absence of > multiple content elements. xml:lang refers to the language of the attributes and child elements, not to the language of the linked resource. We'd need to use hreflang for that, or as you say, use an Accept-Language header. Although: I don't know many FTP servers that know how to handle an Accept-Language header, for those links with an ftp:// URI, such as a link to the newest draft-ietf-atompub-protocol-02.txt document ;-) hreflang is useful when Accept-Language is unsupported (whether by the protocol or the user-agent or the server). e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:56:28 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 XAA25233 for ; Fri, 8 Oct 2004 23:56:27 -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 i993mb2W007857; Fri, 8 Oct 2004 20:48:37 -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 i993mb4J007856; Fri, 8 Oct 2004 20:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i993majC007843 for ; Fri, 8 Oct 2004 20:48:36 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 15027 invoked by uid 65534); 9 Oct 2004 03:48:37 -0000 Received: from dsl-213-023-057-218.arcor-ip.net (EHLO voyager) (213.23.57.218) by mail.gmx.net (mp022) with SMTP; 09 Oct 2004 05:48:37 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Eric Scheid Cc: Atom Syntax Subject: Re: PaceLinkTitle Date: Sat, 09 Oct 2004 05:48:18 +0200 Message-ID: <416c5f1b.755519519@smtp.bjoern.hoehrmann.de> References: <1f2ed5cd041008121114cd2e68@mail.gmail.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Eric Scheid wrote: >but doesn't xml:lang also apply to element attributes? See http://www.w3.org/XML/xml-V10-3e-errata#E01 for the latest thoughts of the XML Core Working Group on this matter. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:57:49 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 XAA25277 for ; Fri, 8 Oct 2004 23:57:49 -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 i993p48d008239; Fri, 8 Oct 2004 20:51:04 -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 i993p42W008238; Fri, 8 Oct 2004 20:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993p3Ks008232 for ; Fri, 8 Oct 2004 20:51:04 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:51:05 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:51:07 +1000 Subject: Re: PaceLinkPurpose From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd04100811144da542b2@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1, but the spec text needs improvement On 9/10/04 4:14 AM, "Danny Ayers" wrote: > But if the definition can be made more useful, then I'd back this > Pace, though would hope that the (controlled) extensibility point > offered by 'rel' wasn't lost in the process. +1 to tackling this problem by suggesting improved camera ready spec text. e. From owner-atom-syntax@mail.imc.org Fri Oct 8 23:59:24 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 XAA25350 for ; Fri, 8 Oct 2004 23:59:23 -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 i993oMC0008176; Fri, 8 Oct 2004 20:50:22 -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 i993oM5Y008175; Fri, 8 Oct 2004 20:50:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41209.mail.yahoo.com (web41209.mail.yahoo.com [66.218.93.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id i993oMAD008075 for ; Fri, 8 Oct 2004 20:50:22 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041009035024.36523.qmail@web41209.mail.yahoo.com> Received: from [24.18.133.31] by web41209.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 20:50:24 PDT Date: Fri, 8 Oct 2004 20:50:24 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceReformedContent3 To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > deaf people often prefer visual communication by > signing over reading text. So a deaf person would rather have someone describe my blog postings to him as sign language than read it? That doesn't sound right at all. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Sat Oct 9 00:00: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 AAA25437 for ; Sat, 9 Oct 2004 00:00: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 i993s2Vl008469; Fri, 8 Oct 2004 20:54: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 i993s2m4008468; Fri, 8 Oct 2004 20:54:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993s0nK008452 for ; Fri, 8 Oct 2004 20:54:01 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:54:02 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 12:32:20 +1000 Subject: Re: PaceLinkDelicious From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd04100811286b0aacb2@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 4:28 AM, "Danny Ayers" wrote: > +0. > > This is simply more evidence that an extensible relationship operator is > needed. -1 This is just PaceLinkAttrDefaults with 'about' added as a choice. Will we be seeing more paces asking for more individual @rels to add to PaceLinkAttrDefaults until once again we have a long list, only to then see PaceLinkAttrDefaults2 reduce it again ? No thanks. e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:00:49 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 AAA25462 for ; Sat, 9 Oct 2004 00:00:48 -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 i993rw37008447; Fri, 8 Oct 2004 20:53:58 -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 i993rw09008446; Fri, 8 Oct 2004 20:53:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993rvQD008440 for ; Fri, 8 Oct 2004 20:53:58 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:53:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 01:54:23 +1000 Subject: Re: valid dates... From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <0b5a01c4ad38$df4e21f0$200ca8c0@wkearney.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/10/04 11:15 PM, "Bill Kearney" wrote: > If you just left off the timezone you'd be unable to tell when and could end > up with 26 different guesses about it. Was your time noon in California and > thus early evening in London? Or noon in Tokyo and the middle of the night > in New York? or you could use a different algorithm. Tell me, what time is it when you start your ten second countdown to shouting "Happy New Year" on December 31? If I want to refer to that particular moment in time, it would be 2004-12-31T23:59:50. If I want to refer to when that moment in time occurs here in Sydney it would be 2004-12-31T23:59:50+10:00. In London UK it would be 2004-12-31T23:59:50+00:00. They all refer to the same conceptual moment, but it just happens at different times around the world. e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:01: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 AAA25480 for ; Sat, 9 Oct 2004 00:00:59 -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 i993s0tG008459; Fri, 8 Oct 2004 20:54:00 -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 i993s0wu008458; Fri, 8 Oct 2004 20:54:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993rxmv008448 for ; Fri, 8 Oct 2004 20:53:59 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:54:01 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 12:23:31 +1000 Subject: Re: PaceLinkRelMechanism From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd0410081105374f5fbb@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 4:05 AM, "Danny Ayers" wrote: > If there is no clear consensus on this I would suggest it be revisited > with the extensible form of the rel attribute reduced to a simple URI. -1 to this pace, and -1 to struggling to find consensus ... I'm not so sure we really need to try so hard to solve this problem so soon. The theoretical dangers of @rel collisions are pretty slight. oh yeah, -1 on using URIs instead of tokens in @rel. It makes the feed even bulkier, prevents considering the idea of space delimited tokens (+/-), and raises the horrible question of canonicalisation all over again. e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:01: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 AAA25498 for ; Sat, 9 Oct 2004 00:01: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 i993rktn008425; Fri, 8 Oct 2004 20:53: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 i993rkdZ008424; Fri, 8 Oct 2004 20:53:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993riXd008414 for ; Fri, 8 Oct 2004 20:53:45 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:53:44 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:53:46 +1000 Subject: Re: PaceLinkAttrDefaults From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd04100811234922ea3e@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. this pace goes too far. e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:01:42 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 AAA25546 for ; Sat, 9 Oct 2004 00:01:42 -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 i993s5vW008479; Fri, 8 Oct 2004 20:54:05 -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 i993s5XP008478; Fri, 8 Oct 2004 20:54:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993s462008471 for ; Fri, 8 Oct 2004 20:54:05 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:54:06 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:29:21 +1000 Subject: Re: PaceDateOfSubject From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4DD414D5-195F-11D9-BE35-003065EA6144@geckotribe.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -1. Let's leave this to an extension covering the issue more > comprehensively. There's a limit to just how much more is needed before we start getting into specifics of use cases. Eg: An extension could include lots more details to support the calendar event use case, but would that include horoscope-sign elements (to support the birthday use case)? And vice versa, plus throw in other use cases. There are tangible points of improvement in the proposed pace though: * loosening the date format to allow whole day or local-time values * facilitating a date range mechanism (my preference is for doing this in the date format a la ISO 8601) Suggestions for replacement spec text are welcome. e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:03:24 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 AAA25591 for ; Sat, 9 Oct 2004 00:03:24 -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 i993rNca008403; Fri, 8 Oct 2004 20:53: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 i993rNSw008402; Fri, 8 Oct 2004 20:53:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993rMvV008394 for ; Fri, 8 Oct 2004 20:53:22 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:53:24 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:53:26 +1000 Subject: Re: PaceLinkConstruct From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd04100811265a63a364@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 to trying to limit @rel to an enumerated short list. the only redeeming quality is the explicit call for @rev, however that is already mentioned/implied by other paces (and deserves a pace of it's own probably). e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:06:58 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 AAA25951 for ; Sat, 9 Oct 2004 00:06:58 -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 i993v4H7008762; Fri, 8 Oct 2004 20:57:04 -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 i993v4ZY008761; Fri, 8 Oct 2004 20:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i993v3gX008754 for ; Fri, 8 Oct 2004 20:57:03 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Oct 2004 13:57:05 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Oct 2004 13:57:07 +1000 Subject: Re: PaceLinkPurpose From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041008174533.98452.qmail@web41215.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 to limiting to traversable hyperlinks +1 to allowing the possibility for extensibility e. From owner-atom-syntax@mail.imc.org Sat Oct 9 00:27:07 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 AAA27248 for ; Sat, 9 Oct 2004 00:27: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 i994FvYu010755; Fri, 8 Oct 2004 21:15: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 i994Fv48010754; Fri, 8 Oct 2004 21:15:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i994FuFT010743 for ; Fri, 8 Oct 2004 21:15:57 -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 (sccrmhc12) with SMTP id <200410090415560120036vphe>; Sat, 9 Oct 2004 04:15:56 +0000 Date: Fri, 8 Oct 2004 22:15:55 -0600 Subject: Re: PaceLinkConstruct 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: <8E08D7E1-195E-11D9-BE35-003065EA6144@geckotribe.com> Message-Id: 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 Friday, October 8, 2004, at 01:16 PM, Antone Roundy wrote: > I'm +1 on this, with the possible exception of @rev. Revising my position--I breezed too quickly over the part about a closed list of @rel values. -1 to that. +1 to moving the list of values from the API spec to the format spec. +1 to the additional @rel values--they all seem like reasonable additions. 0 to @rev. From owner-atom-syntax@mail.imc.org Sat Oct 9 01:16: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 BAA00014 for ; Sat, 9 Oct 2004 01:16: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 i99557A9015466; Fri, 8 Oct 2004 22:05:07 -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 i995570F015465; Fri, 8 Oct 2004 22:05:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i995572F015430 for ; Fri, 8 Oct 2004 22:05:07 -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 (rwcrmhc13) with SMTP id <200410090505090150037vhee>; Sat, 9 Oct 2004 05:05:09 +0000 Date: Fri, 8 Oct 2004 23:05:08 -0600 Subject: PaceLinkRelPrefixReg (was Re: PaceLinkRelMechanism) 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: Message-Id: 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 Friday, October 8, 2004, at 12:50 PM, Antone Roundy wrote: > On Friday, October 8, 2004, at 12:05 PM, Danny Ayers wrote: >> +1 to the Pace. >> >> As one of the original proponents of this Pace, I stand by the >> original aim - to provide some form of extensibility that has tighter >> constraints than 'anything in another namespace can go anywhere'. I >> haven't seen any other proposals that offer this in a better form. >> > -1. I'd prefer a method where the @rel value is entirely self > contained, rather than referring to a namespace or schema whose prefix > is associated with its URI (or whatever) elsewhere in the document. > To avoid potential collisions, making it self contained would require > one of: a) the use of URIs in @rel, b) registration of all @rel values > or 3) my preference[1]: registration of a prefix, but not of every > value (similar to MIME's prs and vnd subtypes). If this idea is not > quickly trounced, I'll write a proposal. > > [1] http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- #5 > Having heard no objections, and having gotten one off-list +1, I've written PaceLinkRelPrefixReg http://www.intertwingly.net/wiki/pie/PaceLinkRelPrefixReg The proposed spec text follows. I imagine it will have to be altered somewhat to clarify where to go to register with IANA[1?]. I assume this would go into a new section in the Directory of General Assigned Numbers[2]: 3.4.1 rel This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. Link Constructs MUST have a rel attribute, whose value MUST be a string, and MAY either be one of the values enumerated below or be defined externally. Externally defined values MUST begin with a prefix which has been registered with IANA. Only the registrant of the prefix can define values beginning with that prefix. Prefixes and the values that follow them MUST be separated by a hyphen, and both MUST consist entirely of alphanumeric characters. The value of this attribute is case-insensitive. [1] http://www.iana.org/cgi-bin/assignments.pl [2] http://www.iana.org/numbers.html From owner-atom-syntax@mail.imc.org Sat Oct 9 06:21: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 GAA01212 for ; Sat, 9 Oct 2004 06:21: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 i99ACJ9V027919; Sat, 9 Oct 2004 03:12: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 i99ACJCw027918; Sat, 9 Oct 2004 03:12:19 -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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99ACIqn027908 for ; Sat, 9 Oct 2004 03:12:18 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so72360rnk for ; Sat, 09 Oct 2004 03:12:26 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr582006rnh; Sat, 09 Oct 2004 03:12:26 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 03:12:26 -0700 (PDT) Message-ID: <1f2ed5cd0410090312605451ef@mail.gmail.com> Date: Sat, 9 Oct 2004 12:12:26 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Eric Scheid Subject: Re: PaceReplaceLinkElement Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0410081217ed68986@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric, I agree entirely. But I interpreted the Pace as suggesting replacement elements for core terms that could be expressed in a clearer fashion, that's what my +1 was for, not getting rid of it as an extension point. Perhaps this needs refactoring into PaceRefactorLinkElement..? On Sat, 09 Oct 2004 13:15:47 +1000, Eric Scheid wrote: > > -1 > > linking resources is too fundamental to require yet another extension module > every time someone wants to express a link with a new relationship. > > e. > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 06:33:26 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 GAA02235 for ; Sat, 9 Oct 2004 06:33: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 i99APb9g032310; Sat, 9 Oct 2004 03:25:37 -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 i99APb06032309; Sat, 9 Oct 2004 03:25:37 -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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99APbWo032283 for ; Sat, 9 Oct 2004 03:25:37 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so72574rnk for ; Sat, 09 Oct 2004 03:25:42 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr581126rnf; Sat, 09 Oct 2004 03:25:42 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 03:25:42 -0700 (PDT) Message-ID: <1f2ed5cd04100903251972f05a@mail.gmail.com> Date: Sat, 9 Oct 2004 12:25:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Atom Syntax Subject: Re: PaceLinkRelMechanism In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0410081105374f5fbb@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [oops - forgot the cc] On Sat, 09 Oct 2004 12:23:31 +1000, Eric Scheid wrote: > > On 9/10/04 4:05 AM, "Danny Ayers" wrote: > > > If there is no clear consensus on this I would suggest it be revisited > > with the extensible form of the rel attribute reduced to a simple URI. > > -1 to this pace, and -1 to struggling to find consensus ... I'm not so sure > we really need to try so hard to solve this problem so soon. The theoretical > dangers of @rel collisions are pretty slight. I don't understand - are you suggesting that @rel should be arbitrary strings? > oh yeah, -1 on using URIs instead of tokens in @rel. It makes the feed even > bulkier, I don't think half-a-dozen or so extra chars in a link are a big deal, especially compared with the restriction of having an ennumerated set of tokens and/or creating a new token mechanism. >prevents considering the idea of space delimited tokens (+/-), I mut have missed that bit - I'm assuming you mean having multiple tokens in a rel? What's wrong with using spaces? (Are multiple tokens going to be common enough to justify this option rather than simply having multiple link elements?) >and > raises the horrible question of canonicalisation all over again. Not necessarily - it would make sense to use the existing definitions. Cheers, Danny. From owner-atom-syntax@mail.imc.org Sat Oct 9 06:34:36 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 GAA02328 for ; Sat, 9 Oct 2004 06:34: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 i99AQhwb032699; Sat, 9 Oct 2004 03:26:43 -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 i99AQh6l032698; Sat, 9 Oct 2004 03:26:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id i99AQgHZ032654 for ; Sat, 9 Oct 2004 03:26:43 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 8490 messnum 2010890 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 9 Oct 2004 10:26:45 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail09.svc.cra.dublin.eircom.net (qp 8490) with SMTP; 9 Oct 2004 10:26:45 -0000 Message-ID: <4167BCE4.3090005@dehora.net> Date: Sat, 09 Oct 2004 11:26:44 +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: PaceLinkRelMechanism References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <1f2ed5cd0410081135d7137c9@mail.gmail.com> <1f2ed5cd04100811564ecb0089@mail.gmail.com> In-Reply-To: <1f2ed5cd04100811564ecb0089@mail.gmail.com> 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 Danny Ayers wrote: > On Fri, 8 Oct 2004 19:42:07 +0100, Graham wrote: > >>If we end up going with it people will key off the QNames. >> >>I've just read the proposal properly and noticed it reuses the same >>prefixes as the XML namespaces. Yuck. > > > You will then have noticed Norm's remark - "The announcement that the > next version of HTML is going to use QNames in rel puts this question > to bed, I think. Using anything else in Atom would be hard to defend." -1 on QName mechanism. I think I said this here once before, but that is HTML's problem, not Atom's. Placing QNames in content is misguided - not something I would want to see propagated in Atom. cheers Bill From owner-atom-syntax@mail.imc.org Sat Oct 9 06:40:11 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 GAA02846 for ; Sat, 9 Oct 2004 06:40:11 -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 i99AToM0033804; Sat, 9 Oct 2004 03:29: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 i99ATobt033803; Sat, 9 Oct 2004 03:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id i99ATmX2033764 for ; Sat, 9 Oct 2004 03:29:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 2867 messnum 6495638 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 9 Oct 2004 10:22:23 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail12.svc.cra.dublin.eircom.net (qp 2867) with SMTP; 9 Oct 2004 10:22:23 -0000 Message-ID: <4167BBDE.9060103@dehora.net> Date: Sat, 09 Oct 2004 11:22:22 +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: PaceLinkRelMechanism References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <1f2ed5cd0410081135d7137c9@mail.gmail.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 Graham wrote: > If we end up going with it people will key off the QNames. > > Whoever wrote this crap needs to > read up on abstraction and separation between processing layers. Rudeness objection. cheers Bill From owner-atom-syntax@mail.imc.org Sat Oct 9 06:55:19 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 GAA03525 for ; Sat, 9 Oct 2004 06:55:19 -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 i99Am3kP040788; Sat, 9 Oct 2004 03:48:03 -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 i99Am3M2040786; Sat, 9 Oct 2004 03:48:03 -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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99Alun4040725 for ; Sat, 9 Oct 2004 03:48:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so72871rnk for ; Sat, 09 Oct 2004 03:48:02 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr585035rnf; Sat, 09 Oct 2004 03:48:02 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 03:48:02 -0700 (PDT) Message-ID: <1f2ed5cd04100903481a75b3cb@mail.gmail.com> Date: Sat, 9 Oct 2004 12:48:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Antone Roundy Subject: Re: PaceLinkRelPrefixReg (was Re: PaceLinkRelMechanism) Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I favour the extensibility, but am not convinced this is a good approach. Your rationale against URIs is: "Using URIs as @rel values would result in larger feeds, and would look messier" - neither is exactly a big deal, see example below. If the URI is well chosen, the only non-informational characters in it in this context are those of the scheme. But having to register namespaces IANA-style significantly raises the bar to entry, centralizing control and demanding a new mechanism for interpretation and new infrastructure to support the registry. That's all Web -1.0 stuff. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 10:35:22 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 KAA17513 for ; Sat, 9 Oct 2004 10:35:22 -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 i99EPsMt064278; Sat, 9 Oct 2004 07:25:54 -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 i99EPsxr064277; Sat, 9 Oct 2004 07:25:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99EPrfe064271 for ; Sat, 9 Oct 2004 07:25:54 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i99EPcCg026687 for ; Sat, 9 Oct 2004 15:25:44 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-913139219; protocol="application/pkcs7-signature" Message-Id: <183B42A6-19FF-11D9-81AD-000A2797ECDA@mac.com> From: Graham Subject: Re: PaceLinkPurpose Date: Sat, 9 Oct 2004 15:25:39 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-913139219 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 8 Oct 2004, at 8:10 pm, Antone Roundy wrote: > I see "alternate" as a "related" type, though I'd agree it's possible > to make a distinction. I'm just not sure it's terribly useful to do > so. Alternate is another version of what your already seeing. Related, via etc all link to things that are completely different. >> image - favicons and logos > These haven't made it into the link element yet, though they've > appeared in proposals. There's no canonical list. Last I checked the format spec just refers you to the list in the protocol spec, which has what can at best be described as a placeholder for a real list. Graham --Apple-Mail-2-913139219 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA5MTQyNTM5WjAjBgkqhkiG9w0BCQQxFgQUBOGSbBVtLBkVdqEesDn+KMZp uvUweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAU5IH4GD+qBTUnnqpqp3QI/3i aSqm7qsZEAwLeSCDm8EKXx6VwGJWGEi0QAuzSvAFknH+ipV9/9Va5654eBuow10NHXeogdCqZFsE wVh0ebnxtubF+eBskN2pkySE/bo0RXQkcCszyUX2MlZvX1covSGtKrc9NciiAFVZc+oZ1+BK1LW9 +igTGVkh7eswQMysp8o49NEZJxrHsvF/qY/Qbkqrn/zJ1ENQNaTpSnFsdgOnPD6T8egY7tc2x5z+ wZKsSpSV0PrbcixEMeWY1nBjcAHGjhc9YiQ/xA6j4//U1M5PDlDvDSFScDsjcOi7MTnZa9u72XM7 NS/6lokTK50xJQAAAAAAAA== --Apple-Mail-2-913139219-- From owner-atom-syntax@mail.imc.org Sat Oct 9 10:35: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 KAA17548 for ; Sat, 9 Oct 2004 10:35: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 i99EQfWb064308; Sat, 9 Oct 2004 07:26: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 i99EQfJU064307; Sat, 9 Oct 2004 07:26:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99EQd4U064285 for ; Sat, 9 Oct 2004 07:26:40 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 10 Oct 2004 00:26:14 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 10 Oct 2004 00:16:39 +1000 Subject: Re: PaceLinkRelMechanism From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd041009032411f9b50c@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9/10/04 8:24 PM, "Danny Ayers" wrote: > On Sat, 09 Oct 2004 12:23:31 +1000, Eric Scheid > wrote: > >> On 9/10/04 4:05 AM, "Danny Ayers" wrote: >> >>> If there is no clear consensus on this I would suggest it be revisited with >>> the extensible form of the rel attribute reduced to a simple URI. >>> >> -1 to this pace, and -1 to struggling to find consensus ... I'm not so sure >> we really need to try so hard to solve this problem so soon. The theoretical >> dangers of @rel collisions are pretty slight. >> > I don't understand - are you suggesting that @rel should be arbitrary strings? > I'm saying the likelihood of an actual collision is so low because we still have a relatively small community. Given the low risk, it's not something which should hold back the idea of an extensible list of @rel values (vs. limiting ourselves to an enumerated list). >> oh yeah, -1 on using URIs instead of tokens in @rel. It makes the feed even >> bulkier, >> > I don't think half-a-dozen or so extra chars in a link are a big deal, > especially compared with the restriction of having an ennumerated set of > tokens and/or creating a new token mechanism. > "http://" is seven characters, plus a domain name, plus another slash, plus whatever comes next, plus what would normally be the @rel value (eg. "next"). That's a lot of extra characters. I hope your not suggesting relative URIs, especially since we'd want to see the same tokens used by multiple publishers (plus the problem of canonicalising relative URIs for comparison purposes). >> prevents considering the idea of space delimited tokens (+/-), >> > I mut have missed that bit - I'm assuming you mean having multiple tokens in a > rel? What's wrong with using spaces? > well, doesn't completely prevent them. certainly makes it messy to think about it though ... there's only one other instance of an element which can have space delimited URIs versus an uncounted number which have just the one URI value. > (Are multiple tokens going to be common enough to justify this option rather > than simply having multiple link elements?) > maybe, maybe not, that's why I wrote (+/-). I like the idea of being able to inject qualifiers. eg. @rel="via trusted xfn.employer" or @rel="next precache" >> and raises the horrible question of canonicalisation all over again. >> > Not necessarily - it would make sense to use the existing definitions. > existing definitions of canonicalisation? e. From owner-atom-syntax@mail.imc.org Sat Oct 9 10:39:04 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 KAA17879 for ; Sat, 9 Oct 2004 10:39: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 i99EUsu7064514; Sat, 9 Oct 2004 07:30:54 -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 i99EUspk064513; Sat, 9 Oct 2004 07:30:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99EUrhh064503 for ; Sat, 9 Oct 2004 07:30:54 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i99EUXrU027530; Sat, 9 Oct 2004 15:30:33 +0100 (BST) In-Reply-To: <4166C99A.4040603@intertwingly.net> References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-913433608; protocol="application/pkcs7-signature" Message-Id: Cc: Atom-Syntax From: Graham Subject: Re: New AtomPubIssuesList for 2004/10/08 Date: Sat, 9 Oct 2004 15:30:33 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4-913433608 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 8 Oct 2004, at 6:08 pm, Sam Ruby wrote: > PaceLinkAttrDefaults > PaceLinkConstruct > PaceLinkDelicious > PaceLinkParent > PaceLinkPurpose > PaceLinkRelMechanism > PaceLinkTitle > PaceReplaceLinkElement Given the discussion that's already occurred in the last day, I think you need to forget discussing specific proposals and ask some consensus finding questions re: the direction in which metadata containing URIs can be extended. Graham (PS I sent a blank email to Sam while composing this - sorry) --Apple-Mail-4-913433608 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA5MTQzMDM0WjAjBgkqhkiG9w0BCQQxFgQUNiVdwGUEXWjRnamOuicHazqU DZgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAk80h09hHH3JOT0C3Qp3eJ2Kr bsZZkReOXZ/A/w+MNjBfLyh1j2vLUiPDzfLg4MkqrMOARFPQflJCwK/Uk8djfvBQadruAOHQdq8S PznTtwIJpt42UPsy2K/kj/ANvD/3yrcUifhJweDTQ7tOr0bqMzn5WgMqX58cJPop1JLWOSxR9QXJ +AZihPiZ4AYvKQ71n7bxgtYyMhbGL1JcvaW+UwIhsixiGKbDEwjv1rUBp47KH/R0XRabd3Sb7iGb ++vNwGaMhjJ5tDowe5/JKPaeSxwEfLecbTrdPfWD3NLk9dd8SbDbtpPS6QFS5uTw8ybWwf5xffaP DHJ24NQFfzVfrgAAAAAAAA== --Apple-Mail-4-913433608-- From owner-atom-syntax@mail.imc.org Sat Oct 9 10:43:09 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 KAA17988 for ; Sat, 9 Oct 2004 10:43:08 -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 i99EYt3b064876; Sat, 9 Oct 2004 07: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 i99EYtwW064875; Sat, 9 Oct 2004 07:34:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99EYs7b064869 for ; Sat, 9 Oct 2004 07:34:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i99EY3Rr028082; Sat, 9 Oct 2004 15:34:04 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-913644532; protocol="application/pkcs7-signature" Message-Id: <456BF6DD-1A00-11D9-81AD-000A2797ECDA@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceReplaceLinkElement Date: Sat, 9 Oct 2004 15:34:04 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-5-913644532 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 9 Oct 2004, at 4:15 am, Eric Scheid wrote: > -1 > > linking resources is too fundamental to require yet another extension > module > every time someone wants to express a link with a new relationship. Module? What the hell is a module? All you have to do is invent a namespace for yourself and you're done. Graham --Apple-Mail-5-913644532 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA5MTQzNDA1WjAjBgkqhkiG9w0BCQQxFgQU6UJh9gNJ0DVeWAyOWN9VJbXy KswweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEACKSJe9LIP4zC2DVIKYxXej6T /znr+zTsMxkgCf8sEz5vQHvSMJIwHxAk7zUg7QGpBlhgoDzFX7zqb0p1yVBJRvpJ09/OAWqEITVf LFQAsgcY5M4JGbLp5Z40vXiG7ydYHQ19ynC0yFNz6AhjfCT7kfHeUSuaJkhaiijN1JKYDsSzLayt SQ74ll1AWAzAVNCnBZBOWnvdH/IwN2+GxPCP/G9OjLeVYdh8o+AfVi+B0b+6x60pgQbOI4DnqgIt CqWvc2lm+9RYFMHaKm9RUIUlvc4cSVjRpfKVmPg7a15QCiWwU+79elBBEm0MEExV1T9DaoLWo/Qw znP61vIOohGzVAAAAAAAAA== --Apple-Mail-5-913644532-- From owner-atom-syntax@mail.imc.org Sat Oct 9 10:45: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 KAA18123 for ; Sat, 9 Oct 2004 10:45:34 -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 i99EcOBb065104; Sat, 9 Oct 2004 07:38: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 i99EcOk7065103; Sat, 9 Oct 2004 07:38:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99EcNih065091 for ; Sat, 9 Oct 2004 07:38:24 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i99EbXLX028779 for ; Sat, 9 Oct 2004 15:37:33 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20041008173843.10756.qmail@web41213.mail.yahoo.com> References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-913853747; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: PaceLinkRelMechanism Date: Sat, 9 Oct 2004 15:37:33 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-7-913853747 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Motion put to the floor of the house: There is no practicable way to make @rel values extensible. Graham --Apple-Mail-7-913853747 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA5MTQzNzM0WjAjBgkqhkiG9w0BCQQxFgQU/bAvl1pPwQf96NEzforSl6f6 3w0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAW0scxMPosNO++uBpH54pHaa3 UnPhZHKmz2gX4YVlvdEGx6XtEI6ahIaOv+j1xyzhqN4bZCuXY5Q5TjtJy62OGdC0NPvza+R/NSvD Zr6Kf+NDPwdvAzE9Mg0bWDClMjaPGzTyLLubA3dSgkjlAqYK94rSGLQXRV4+6jnBP7o8UUudXp/b iJytlXgdLMiquOHsxte8C27ezgRtV5InOZdPKupvoWgI0qCIvQwy1gyaEwWGBSMisbEoQx2NSdjv l40GjStNa74eq32wdAcDYVJjmTVTw/Ytr6CcxbOhjm/DkdT1IgWS0IKzo5wHNAOSebyEe3CxBAsx aXg3aKm9ymkZBQAAAAAAAA== --Apple-Mail-7-913853747-- From owner-atom-syntax@mail.imc.org Sat Oct 9 11:03:12 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 LAA18843 for ; Sat, 9 Oct 2004 11:03:11 -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 i99ErL4e065971; Sat, 9 Oct 2004 07:53: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 i99ErLOp065970; Sat, 9 Oct 2004 07:53:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99ErKSY065960 for ; Sat, 9 Oct 2004 07:53:20 -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 (rwcrmhc13) with SMTP id <2004100914532501500381sqe>; Sat, 9 Oct 2004 14:53:25 +0000 Date: Sat, 9 Oct 2004 08:53:24 -0600 Subject: Re: PaceLinkRelPrefixReg (was Re: PaceLinkRelMechanism) 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: <1f2ed5cd04100903481a75b3cb@mail.gmail.com> Message-Id: 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 Saturday, October 9, 2004, at 04:48 AM, Danny Ayers wrote: > Your rationale against URIs is: "Using URIs as @rel values would > result in larger feeds, and would look messier" - neither is exactly a > big deal True, not every part of the rationale is as important as the others. A bigger issue with URIs (which I just added to the Pace) is that they would raise the issue of canonicalization again. > But having to register namespaces IANA-style significantly raises the > bar to entry ...which may or may not not be a bad thing. Quoting[1] Sam from a while back: "At the moment, I'm leaning towards [snip] establishing a registration scheme for new values. Hopefully the registration scheme will be hairy enough to scare away fivilous and unproven suggestions. Hmmm, seems to me like IANA might fit that bill." Prefix registration is aimed at falling somewhere between the difficulty of registering every value and solutions which require no registration at all. [1] http://www.imc.org/atom-syntax/mail-archive/msg07393.html From owner-atom-syntax@mail.imc.org Sat Oct 9 11:30:43 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 LAA20589 for ; Sat, 9 Oct 2004 11:30:42 -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 i99FM888067624; Sat, 9 Oct 2004 08:22: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 i99FM8OJ067623; Sat, 9 Oct 2004 08:22:08 -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 i99FM86v067617 for ; Sat, 9 Oct 2004 08:22:08 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.102]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGJ2z-0001OX-Rm; Sat, 09 Oct 2004 15:22:13 +0000 Message-ID: <41680228.7040401@franklinmint.fm> Date: Sat, 09 Oct 2004 11:22:16 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom Syntax Subject: rel values References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > Motion put to the floor of the house: > > There is no practicable way to make @rel values extensible. > Seconded. QNames in attribute values is a bad idea. We will never reach consensus to do it. Why not use atom:href in extension elements? Get every link in the document like this: //*[@atom:href] Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 9 11:42: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 LAA21391 for ; Sat, 9 Oct 2004 11:42: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 i99FYQD0068234; Sat, 9 Oct 2004 08:34:27 -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 i99FYQ40068233; Sat, 9 Oct 2004 08:34:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id i99FYPZ5068221 for ; Sat, 9 Oct 2004 08:34:26 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 90232 messnum 2041637 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 9 Oct 2004 15:34:30 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail03.svc.cra.dublin.eircom.net (qp 90232) with SMTP; 9 Oct 2004 15:34:30 -0000 Message-ID: <41680503.8060000@dehora.net> Date: Sat, 09 Oct 2004 16:34:27 +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: PaceLinkRelMechanism References: <20041008173843.10756.qmail@web41213.mail.yahoo.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 Graham wrote: > Motion put to the floor of the house: > > There is no practicable way to make @rel values extensible. I agree; it's difficult to stuff an extensiblilty model into an attribute. If there is a practical way, it will probably be easier for someone to find if we spec the use of URIs. cheers Bill From owner-atom-syntax@mail.imc.org Sat Oct 9 11:46:48 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 LAA21691 for ; Sat, 9 Oct 2004 11:46:47 -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 i99Fd7KV068534; Sat, 9 Oct 2004 08:39:07 -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 i99Fd7kW068533; Sat, 9 Oct 2004 08:39:07 -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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99Fd765068522 for ; Sat, 9 Oct 2004 08:39:07 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so77251rnk for ; Sat, 09 Oct 2004 08:39:12 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr639712rnf; Sat, 09 Oct 2004 08:39:12 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 08:39:12 -0700 (PDT) Message-ID: <1f2ed5cd04100908394cd7cfd4@mail.gmail.com> Date: Sat, 9 Oct 2004 17:39:12 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: New AtomPubIssuesList for 2004/10/08 Cc: Sam Ruby , Atom-Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 9 Oct 2004 15:30:33 +0100, Graham wrote: > On 8 Oct 2004, at 6:08 pm, Sam Ruby wrote: > > > PaceLinkAttrDefaults > > PaceLinkConstruct > > PaceLinkDelicious > > PaceLinkParent > > PaceLinkPurpose > > PaceLinkRelMechanism > > PaceLinkTitle > > PaceReplaceLinkElement > > Given the discussion that's already occurred in the last day, I think > you need to forget discussing specific proposals and ask some consensus > finding questions re: the direction in which metadata containing URIs > can be extended. Yep, though there are kind-of architectural patterns in these Paces, so I think it may be possible to keep it in the confines of and break it down a little to get consensus on parts. There are only a few (in principle, broadly) orthogonal questions, first pass - * which link rel values should be refactored out into elements in their own right? * should [whatever remains of] link have its semantics narrowed? (e.g. to "things on which a GET might work", other groupings or totally removed) * should [whatever remains of] link be used as an extension point? (later - what relation naming mechanism should be used?) Not sure how they can be massaged in with the process though... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 11:47: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 LAA21723 for ; Sat, 9 Oct 2004 11:47: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 i99FcrIF068499; Sat, 9 Oct 2004 08:38: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 i99FcrKH068498; Sat, 9 Oct 2004 08:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i99FcqZq068490 for ; Sat, 9 Oct 2004 08:38:52 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041009153858.79660.qmail@web41210.mail.yahoo.com> Received: from [67.160.81.190] by web41210.mail.yahoo.com via HTTP; Sat, 09 Oct 2004 08:38:58 PDT Date: Sat, 9 Oct 2004 08:38:58 -0700 (PDT) From: Dare Obasanjo Subject: Re: rel values To: Robert Sayre , Graham Cc: Atom Syntax In-Reply-To: <41680228.7040401@franklinmint.fm> 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: --- Robert Sayre wrote: > > Graham wrote: > > > Motion put to the floor of the house: > > > > There is no practicable way to make @rel values > extensible. > > Why not use atom:href in extension elements? > > Get every link in the document like this: > > //*[@atom:href] I don't think anyone has ever complained about the syntax so your proposed solution does nothing to change the problem. The problem being, exactly what is the semantics of a link so consumers of Atom feeds can know how to process them in a uniform manner. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 9 11:53: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 LAA22105 for ; Sat, 9 Oct 2004 11:53: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 i99Fkos5068943; Sat, 9 Oct 2004 08:46: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 i99Fko6s068942; Sat, 9 Oct 2004 08:46: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 i99FknW5068927 for ; Sat, 9 Oct 2004 08:46:50 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i99FlV2L011912; Sat, 9 Oct 2004 11:47:31 -0400 Message-ID: <416807E2.5090408@intertwingly.net> Date: Sat, 09 Oct 2004 11:46:42 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom-Syntax Subject: Re: New AtomPubIssuesList for 2004/10/08 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.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 Graham wrote: > On 8 Oct 2004, at 6:08 pm, Sam Ruby wrote: > >> PaceLinkAttrDefaults >> PaceLinkConstruct >> PaceLinkDelicious >> PaceLinkParent >> PaceLinkPurpose >> PaceLinkRelMechanism >> PaceLinkTitle >> PaceReplaceLinkElement > > Given the discussion that's already occurred in the last day, I think > you need to forget discussing specific proposals and ask some consensus > finding questions re: the direction in which metadata containing URIs > can be extended. We recently had a round on extensibility. The mailing list also contains a number of people who seem to prefer to traffic in what Dan Brickley referred to as a "snipey style of interaction". I'd like to try to give equal time to the people who can manage to express coherent, constructive, and specific suggestions. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Oct 9 11:53:19 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 LAA22131 for ; Sat, 9 Oct 2004 11:53:19 -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 i99Fkoxg068934; Sat, 9 Oct 2004 08:46: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 i99Fkopu068933; Sat, 9 Oct 2004 08:46:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99FkoRt068920 for ; Sat, 9 Oct 2004 08:46:50 -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 (rwcrmhc13) with SMTP id <20041009154655015003d3hte>; Sat, 9 Oct 2004 15:46:55 +0000 Date: Sat, 9 Oct 2004 09:46:54 -0600 Subject: Re: rel values 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: <41680228.7040401@franklinmint.fm> Message-Id: <71B07FA2-1A0A-11D9-B794-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 Saturday, October 9, 2004, at 09:22 AM, Robert Sayre wrote: > Graham wrote: >> Motion put to the floor of the house: >> There is no practicable way to make @rel values extensible. > > Seconded. QNames in attribute values is a bad idea. We will never > reach consensus to do it. > > Why not use atom:href in extension elements? > > Get every link in the document like this: > > //*[@atom:href] So any element that contains @atom:href is a Link Construct, with all the attributes required of a Link Construct, and no additional attributes or child content/elements that need to be understood to be able to process it properly? Or can you not infer that? If not, then the usefulness of this approach is extremely limited. Of course, I'm not saying I'm entirely opposed to this approach--I did, after all, write PaceExtensionNamespace, the core idea of which is this. But I myself have since decided I'd prefer a different approach. One possibility is PaceLinkRelPrefixReg (which does not use QNames in attributes), and another is #6 in http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- use @atom:construct to identify what Atom Construct an extension element follows the rules for. For example, If becomes popular enough, @atom:construct could eventually be dropped from it, since most aggregators would know it was a Link Construct without the hint (and in fact, @atom:construct could, and probably should, be optional from the beginning). Once again, if the idea isn't quickly trounced, I'll write a proposal, so that we can have something concrete to discuss. From owner-atom-syntax@mail.imc.org Sat Oct 9 12:08:23 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 MAA22752 for ; Sat, 9 Oct 2004 12:08:23 -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 i99G1esm069695; Sat, 9 Oct 2004 09:01: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 i99G1eER069694; Sat, 9 Oct 2004 09:01:40 -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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99G1doq069688 for ; Sat, 9 Oct 2004 09:01:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so77677rnk for ; Sat, 09 Oct 2004 09:01:45 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr649170rnh; Sat, 09 Oct 2004 09:01:45 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 09:01:45 -0700 (PDT) Message-ID: <1f2ed5cd04100909014d2bef6b@mail.gmail.com> Date: Sat, 9 Oct 2004 18:01:45 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: rel values Cc: Graham , Atom Syntax In-Reply-To: <41680228.7040401@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <41680228.7040401@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 09 Oct 2004 11:22:16 -0400, Robert Sayre wrote: > > Graham wrote: > > > Motion put to the floor of the house: > > > > There is no practicable way to make @rel values extensible. > > Why aren't URIs practicable? > Seconded. QNames in attribute values is a bad idea. We will never reach > consensus to do it. Ok. Same question again. > Why not use atom:href in extension elements? > > Get every link in the document like this: > > //*[@atom:href] You mean something like: ? That sounds workable, assuming you also had something saying what the anchor/subject of the link/relationship was (presumably the parent element) - e.g. if the element above was an immediate child of the image would be a depiction of the entry, inside it would be a depiction of the the author etc. If this were fleshed out a little I for one would be happy to drop as an extensibility point. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 12:24: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 MAA23648 for ; Sat, 9 Oct 2004 12:24: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 i99GG06b070716; Sat, 9 Oct 2004 09:16:00 -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 i99GG0Gd070715; Sat, 9 Oct 2004 09:16:00 -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 i99GG0h7070709 for ; Sat, 9 Oct 2004 09:16:00 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.102]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGJt9-0003KP-LC; Sat, 09 Oct 2004 16:16:07 +0000 Message-ID: <41680ECA.9050107@franklinmint.fm> Date: Sat, 09 Oct 2004 12:16:10 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Graham , Atom Syntax Subject: Re: rel values References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> In-Reply-To: <20041009153858.79660.qmail@web41210.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > --- Robert Sayre wrote: > > >>Graham wrote: >> >> >>>Motion put to the floor of the house: >>> >>>There is no practicable way to make @rel values >> >>extensible. >> >>Why not use atom:href in extension elements? >> >>Get every link in the document like this: >> >>//*[@atom:href] > > > I don't think anyone has ever complained about the > syntax so your proposed solution does nothing to > change the problem. False. Here on atom-syntax, numerous people have complained about the syntax, because it has all the problems of HTML4's link tag. > The problem being, exactly what is > the semantics of a link so consumers of Atom feeds can > know how to process them in a uniform manner. Here's the definition of a link I like to use: "A link is a connection from one Web resource to another. Although a simple concept, the link has been one of the primary forces driving the success of the Web. The default behavior associated with a link is the retrieval of another Web resource."[0] In other words, if you don't want it retrieved, don't put it in a link. Other information might be associated with the relationship. The class of Atom consumers known as aggregators can render unknown links in a manner similar to the Mozilla web browser's "Site Navigation Bar", or skip them all together. Robert Sayre [0] http://www.w3.org/TR/REC-html40/struct/links.html From owner-atom-syntax@mail.imc.org Sat Oct 9 12:29: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 MAA23841 for ; Sat, 9 Oct 2004 12:29: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 i99GL0oY070969; Sat, 9 Oct 2004 09:21:00 -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 i99GL0Y1070968; Sat, 9 Oct 2004 09:21:00 -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 i99GL0XT070958 for ; Sat, 9 Oct 2004 09:21:00 -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 <2004100916210501400rm7e2e>; Sat, 9 Oct 2004 16:21:06 +0000 Date: Sat, 9 Oct 2004 10:21:05 -0600 Subject: Re: rel values 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: <71B07FA2-1A0A-11D9-B794-003065EA6144@geckotribe.com> Message-Id: <37FFDFA4-1A0F-11D9-B794-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 Saturday, October 9, 2004, at 09:46 AM, Antone Roundy wrote: > #6 in http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- use > @atom:construct to identify what Atom Construct an extension element > follows the rules for. For example, > > > > If becomes popular enough, @atom:construct could > eventually be dropped from it, since most aggregators would know it > was a Link Construct without the hint (and in fact, @atom:construct > could, and probably should, be optional from the beginning). > > Once again, if the idea isn't quickly trounced, I'll write a proposal, > so that we can have something concrete to discuss. Okay, I had a spare minute, so I went ahead an wrote an indirectly competing proposal for the one I wrote yesterday without waiting to be trounced. http://www.intertwingly.net/wiki/pie/PaceConstructAttribute Here's the proposed spec text: X.X.X. atom:construct attribute This attribute MAY be used by extension elements to indicate that they follow the rules defined in this specification for some type of Construct. The value of this attribute MUST be one of "link", "date", or "person". The value MUST be lowercase. Elements containing this attribute MUST include all of the attributes and child content required by this specification for the named Construct type. They MUST NOT contain additional attributes or child content which is required in order to process the element in an acceptable manner. Example: The following indicates that myext:mylink is a Link Construct, as defined by this specification: From owner-atom-syntax@mail.imc.org Sat Oct 9 12:30: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 MAA23937 for ; Sat, 9 Oct 2004 12:30:50 -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 i99GNf83071108; Sat, 9 Oct 2004 09:23: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 i99GNfna071107; Sat, 9 Oct 2004 09:23:41 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99GNeWJ071101 for ; Sat, 9 Oct 2004 09:23:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so78080rnk for ; Sat, 09 Oct 2004 09:23:51 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr653965rnh; Sat, 09 Oct 2004 09:23:51 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 09:23:51 -0700 (PDT) Message-ID: <1f2ed5cd04100909235dc86cd3@mail.gmail.com> Date: Sat, 9 Oct 2004 18:23:51 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: rel values Cc: Robert Sayre , Graham , Atom Syntax In-Reply-To: <20041009153858.79660.qmail@web41210.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41680228.7040401@franklinmint.fm> <20041009153858.79660.qmail@web41210.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 9 Oct 2004 08:38:58 -0700 (PDT), Dare Obasanjo wrote: > > I don't think anyone has ever complained about the > syntax I got the impression the first post in this thread was doing just that. so your proposed solution does nothing to > change the problem. The problem being, exactly what is > the semantics of a link so consumers of Atom feeds can > know how to process them in a uniform manner. That's not difficult - "The link construct defines a binary relationship between the parent of the element in which it appears, and the resource identified in the atom:href attribute. The nature of that relationship is detemined by the name of the element containing the atom:href attribute. If that name is in the Atom namespace, then a consumer MUST interpret it and behave according to the definition of that term in this specification. Otherwise the consumer MAY follow whatever definition is provided for the the term in the namespace in question. If the consumer has no knowledge of the term then it MAY ignore it or present the data to the end user in any manner deemed appropriate". Examples (something like): http://example.org/blah ... This says: the edit endpoint using the Atom Protocol for the resource http://example.org/blah is http://example.org/editme. http://example.org/blah ... This says: http://example.org/veg.jgp is a foaf:Image which depicts the resource http://example.org/blah Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 12:36: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 MAA24212 for ; Sat, 9 Oct 2004 12:36:46 -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 i99GU2HQ071424; Sat, 9 Oct 2004 09:30: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 i99GU2ee071423; Sat, 9 Oct 2004 09:30:02 -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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99GU181071417 for ; Sat, 9 Oct 2004 09:30:01 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so78196rnk for ; Sat, 09 Oct 2004 09:30:09 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr645948rnf; Sat, 09 Oct 2004 09:30:08 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 09:30:08 -0700 (PDT) Message-ID: <1f2ed5cd041009093056b0fe54@mail.gmail.com> Date: Sat, 9 Oct 2004 18:30:08 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: rel values Cc: Dare Obasanjo , Graham , Atom Syntax In-Reply-To: <41680ECA.9050107@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 09 Oct 2004 12:16:10 -0400, Robert Sayre wrote: > Here's the definition of a link I like to use: > > "A link is a connection from one Web resource to another. Although a > simple concept, the link has been one of the primary forces driving the > success of the Web. > > The default behavior associated with a link is the retrieval of another > Web resource."[0] I've no objection whatsoever to the element being defined in this way, as long as there is still a uniform means of defining arbitrary relationships between Atom resources and other resources. This could be provided by Paul's mechanism (replace 'link construct' with 'relationship construct' in the definition I offered). This might just give us the best of both worlds. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 12:41:43 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 MAA24457 for ; Sat, 9 Oct 2004 12:41:43 -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 i99GX8OS071629; Sat, 9 Oct 2004 09:33: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 i99GX82i071628; Sat, 9 Oct 2004 09:33:08 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99GX8gq071622 for ; Sat, 9 Oct 2004 09:33:08 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so78275rnk for ; Sat, 09 Oct 2004 09:33:12 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr651838rnf; Sat, 09 Oct 2004 09:33:11 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 09:33:11 -0700 (PDT) Message-ID: <1f2ed5cd041009093312cf1a7a@mail.gmail.com> Date: Sat, 9 Oct 2004 18:33:11 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: rel values Cc: Dare Obasanjo , Graham , Atom Syntax In-Reply-To: <1f2ed5cd041009093056b0fe54@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry, that should have read "...Robert's mechanism...". On Sat, 9 Oct 2004 18:30:08 +0200, Danny Ayers wrote: > On Sat, 09 Oct 2004 12:16:10 -0400, Robert Sayre wrote: > > > Here's the definition of a link I like to use: > > > > "A link is a connection from one Web resource to another. Although a > > simple concept, the link has been one of the primary forces driving the > > success of the Web. > > > > The default behavior associated with a link is the retrieval of another > > Web resource."[0] > > I've no objection whatsoever to the element being defined in > this way, as long as there is still a uniform means of defining > arbitrary relationships between Atom resources and other resources. > This could be provided by Paul's mechanism (replace 'link construct' > with 'relationship construct' in the definition I offered). > > This might just give us the best of both worlds. > > > > Cheers, > Danny. > > -- > > http://dannyayers.com > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 12:56: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 MAA25386 for ; Sat, 9 Oct 2004 12:56:24 -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 i99GloqU072248; Sat, 9 Oct 2004 09:47: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 i99GloZQ072247; Sat, 9 Oct 2004 09:47:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99Glo4F072237 for ; Sat, 9 Oct 2004 09:47:50 -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 (sccrmhc11) with SMTP id <2004100916475301100k305te>; Sat, 9 Oct 2004 16:47:53 +0000 Date: Sat, 9 Oct 2004 10:47:52 -0600 Subject: Re: rel values 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: <41680ECA.9050107@franklinmint.fm> Message-Id: 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 Saturday, October 9, 2004, at 10:16 AM, Robert Sayre wrote: > The default behavior associated with a link is the retrieval of > another Web resource."[0] > > In other words, if you don't want it retrieved, don't put it in a link. I don't think this is quite narrow enough. I think should be used to retrieve a primary resource. By "primary resource" I mean for example, an HTML page. The HTML page itself may contain pointers to stylesheets, images, etc., which will also be retrieved, but which, in that context, are not the primary resources. That's not to say that those other resources couldn't, in some other context, be primary resources. In such a context, it would be appropriate for to point to them. From owner-atom-syntax@mail.imc.org Sat Oct 9 13:02:56 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 NAA25836 for ; Sat, 9 Oct 2004 13:02:55 -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 i99GuNA8072683; Sat, 9 Oct 2004 09:56: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 i99GuNmq072682; Sat, 9 Oct 2004 09:56:23 -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 i99GuMnK072675 for ; Sat, 9 Oct 2004 09:56:22 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGKWD-0004no-TH; Sat, 09 Oct 2004 16:56:30 +0000 Message-ID: <41681840.7010200@franklinmint.fm> Date: Sat, 09 Oct 2004 12:56:32 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Dare Obasanjo , Graham , Atom Syntax Subject: Re: rel values References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> In-Reply-To: <1f2ed5cd041009093056b0fe54@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > I've no objection whatsoever to the element being defined in > this way, as long as there is still a uniform means of defining > arbitrary relationships between Atom resources and other resources. > This could be provided by Paul's mechanism (replace 'link construct' > with 'relationship construct' in the definition I offered). http://infomesh.net/2002/rdfinhtml/#conclusion We give you a URI to identify a given atom:entry, so there is no need to package assertions in the XML, but you could if you wanted gargantuan Atom entries. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 9 13:03:49 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 NAA25897 for ; Sat, 9 Oct 2004 13:03:48 -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 i99Gt0lv072596; Sat, 9 Oct 2004 09:55:00 -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 i99Gt0gh072595; Sat, 9 Oct 2004 09:55:00 -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 ESMTP id i99GsxhN072589 for ; Sat, 9 Oct 2004 09:54:59 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so78762rnk for ; Sat, 09 Oct 2004 09:54:55 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr656227rnf; Sat, 09 Oct 2004 09:54:55 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 09:54:55 -0700 (PDT) Message-ID: <1f2ed5cd04100909546e01131e@mail.gmail.com> Date: Sat, 9 Oct 2004 18:54:55 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: PaceRelationshipConstruct Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Added to the Wiki. http://www.intertwingly.net/wiki/pie/PaceRelationshipConstruct Abstract Rather than using as a point of extensibility, use the following construct instead: Status Open. Sunny. Rationale A uniform mechanism is needed for defining arbitrary relationships between Atom resources and other resources. This functionality is provided in RSS 1.0 by RDF, but the Atom WG has chosen not to follow this approach. is already overloaded, talk around it is getting nowhere, and one of the points of contention is its use for extensibility. Most if not all of that functionality could be provided by constraining the interpretation of @href when used with elements from foreign namespaces. Proposal Insert the following into the format spec: "Any element containing the attribute atom:href will be considered a component of a relationship construct. This construct defines a binary relationship between the parent of the element in which it appears, and the resource identified in the atom:href attribute. The nature of that relationship is detemined by the name of the element containing the atom:href attribute. If that name is in the Atom namespace, then a consumer MUST interpret it and behave according to the definition of that term in this specification. Otherwise the consumer MAY follow whatever definition is provided for the the term in the namespace in question. If the consumer has no knowledge of the term then it MAY ignore it or present the data to the end user in any manner deemed appropriate". Examples (something like): http://example.org/blah ... This says: the edit endpoint using the Atom Protocol for the resource http://example.org/blah is http://example.org/editme. http://example.org/blah ... This says: http://example.org/veg.jgp is a foaf:Image which depicts the resource http://example.org/blah Impacts Elements from other namespaces which use the atom:href attribute will have their definitions constrained. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 13:15: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 NAA26578 for ; Sat, 9 Oct 2004 13:15: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 i99H66Yr073207; Sat, 9 Oct 2004 10:06: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 i99H66BQ073206; Sat, 9 Oct 2004 10:06:06 -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 i99H65xM073200 for ; Sat, 9 Oct 2004 10:06:05 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGKfd-0005Fq-TA; Sat, 09 Oct 2004 17:06:14 +0000 Message-ID: <41681A89.8070107@franklinmint.fm> Date: Sat, 09 Oct 2004 13:06:17 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: rel values References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Saturday, October 9, 2004, at 10:16 AM, Robert Sayre wrote: > >> The default behavior associated with a link is the retrieval of >> another Web resource."[0] >> >> In other words, if you don't want it retrieved, don't put it in a link. > > > I don't think this is quite narrow enough. I think should be > used to retrieve a primary resource. By "primary resource" I mean for > example, an HTML page. The HTML page itself may contain pointers to > stylesheets, images, etc., which will also be retrieved, but which, in > that context, are not the primary resources. That's not to say that > those other resources couldn't, in some other context, be primary > resources. In such a context, it would be appropriate for to > point to them. > Hmmm. I don't think I understand the distinction you are trying to make. Perhaps you mean resources that would be the focus of a primary viewing window? I don't think requirements on UA behavior are in-bounds here.[0] UAs can make that decision based on type attributes, HEAD requests, etc. Robert Sayre [0] http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af From owner-atom-syntax@mail.imc.org Sat Oct 9 13:17: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 NAA26659 for ; Sat, 9 Oct 2004 13:17:10 -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 i99HAOcS073640; Sat, 9 Oct 2004 10:10: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 i99HAOrk073639; Sat, 9 Oct 2004 10:10:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99HAOib073555 for ; Sat, 9 Oct 2004 10:10:24 -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 (rwcrmhc13) with SMTP id <200410091710290150039ep4e>; Sat, 9 Oct 2004 17:10:29 +0000 Date: Sat, 9 Oct 2004 11:10:28 -0600 Subject: Re: PaceLinkPurpose 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: Message-Id: <1E2AEEB4-1A16-11D9-B794-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 Friday, October 8, 2004, at 08:52 PM, Eric Scheid wrote: > On 9/10/04 5:03 AM, "Antone Roundy" wrote: > [spec text] >> A Link construct specifies a hyperlink primarily intended to be >> activated through explicit user interactions such as clicking, >> selecting a menu item, drag and drop, etc. When accessing the resource >> pointed to by the href attribute using HTTP, the GET method MUST be >> used. > > s/activated/traversed/ ? Yes, that's better. Updated. > Problem: "GET method MUST be used" disallows the use of HEAD for it's > useful > reasons. The intent, iirc, was to disallow POST and similar access > methods > requiring more payload than just the URI. > > It also disallows PROPFIND and OPTIONS and maybe other methods too, but > since I know squat about these I don't know if that is good or bad. > Changed "accessing" to "retrieving", which at least improves it. Any other suggestions for improvement? From owner-atom-syntax@mail.imc.org Sat Oct 9 13:18:55 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 NAA26734 for ; Sat, 9 Oct 2004 13:18:55 -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 i99HBCAF074067; Sat, 9 Oct 2004 10:11: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 i99HBC9N074066; Sat, 9 Oct 2004 10:11:12 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99HBBXH074060 for ; Sat, 9 Oct 2004 10:11:12 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so79142rnk for ; Sat, 09 Oct 2004 10:11:22 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr654897rnf; Sat, 09 Oct 2004 10:11:22 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 10:11:22 -0700 (PDT) Message-ID: <1f2ed5cd041009101118baaf5@mail.gmail.com> Date: Sat, 9 Oct 2004 19:11:22 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: rel values Cc: Dare Obasanjo , Graham , Atom Syntax In-Reply-To: <41681840.7010200@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <41681840.7010200@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 09 Oct 2004 12:56:32 -0400, Robert Sayre wrote: > Danny Ayers wrote: > > > > > I've no objection whatsoever to the element being defined in > > this way, as long as there is still a uniform means of defining > > arbitrary relationships between Atom resources and other resources. > > This could be provided by Paul's mechanism (replace 'link construct' > > with 'relationship construct' in the definition I offered). > > http://infomesh.net/2002/rdfinhtml/#conclusion > > > > > We give you a URI to identify a given atom:entry, so there is no need to > package assertions in the XML, but you could if you wanted gargantuan > Atom entries. Sure. But without some kind of controlled extensions, in a scenario like e.g. weather forecasts you'd end up having to send the human-readable data in an Atom feed and the machine-readable in external documents (a parallel RSS 1.0 feed?). That is of course assuming Atom had a mechanism for pointing to the external documents... Bottom line is there's no need to include assertions like the date or material such as content in a feed either. But it all helps make useful and interesting applications easier. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 13:27: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 NAA27139 for ; Sat, 9 Oct 2004 13:27:46 -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 i99HKVKE074777; Sat, 9 Oct 2004 10:20:31 -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 i99HKVR1074776; Sat, 9 Oct 2004 10:20:31 -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 i99HKU3O074770 for ; Sat, 9 Oct 2004 10:20:30 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGKtX-0005sH-Gb; Sat, 09 Oct 2004 17:20:35 +0000 Message-ID: <41681DE6.8080109@franklinmint.fm> Date: Sat, 09 Oct 2004 13:20:38 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Dare Obasanjo , Graham , Atom Syntax Subject: Re: rel values References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <41681840.7010200@franklinmint.fm> <1f2ed5cd041009101118baaf5@mail.gmail.com> In-Reply-To: <1f2ed5cd041009101118baaf5@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > Sure. But without some kind of controlled extensions, in a scenario > like e.g. weather forecasts you'd end up having to send the > human-readable data in an Atom feed and the machine-readable in > external documents (a parallel RSS 1.0 feed?). > > Bottom line is there's no need to include assertions like the date or > material such as content in a feed either. But it all helps make > useful and interesting applications easier. Is there a problem with using rdf/xml in extensions? Wouldn't want to reinvent RDF. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 9 13:28: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 NAA27166 for ; Sat, 9 Oct 2004 13:27:59 -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 i99HKoJh074825; Sat, 9 Oct 2004 10:20: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 i99HKomC074824; Sat, 9 Oct 2004 10:20:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99HKnO2074816 for ; Sat, 9 Oct 2004 10:20:49 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i99HL0NH004418 for ; Sat, 9 Oct 2004 11:21:00 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5B00GAPUV0IY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 09 Oct 2004 11:21:00 -0600 (MDT) Received: from [192.168.1.24] ([204.174.35.171]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5B00KHFUUZ3N@mail.sun.net> for atom-syntax@imc.org; Sat, 09 Oct 2004 11:21:00 -0600 (MDT) Date: Sat, 09 Oct 2004 10:21:14 -0700 From: Tim Bray Subject: meta-issue: arbitrary relationships required? In-reply-to: <1f2ed5cd041009093056b0fe54@mail.gmail.com> To: Atom Syntax Message-id: <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 9, 2004, at 9:30 AM, Danny Ayers wrote: > as long as there is still a uniform means of defining > arbitrary relationships between Atom resources and other resources. Is this a requirement for Atom? I suggest that it's not. I'd be interested in hearing arguments from prior syndication art or from our charter. -Tim From owner-atom-syntax@mail.imc.org Sat Oct 9 13:28: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 NAA27186 for ; Sat, 9 Oct 2004 13:28: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 i99HIPk0074571; Sat, 9 Oct 2004 10:18:25 -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 i99HIPHQ074570; Sat, 9 Oct 2004 10:18:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99HIObu074562 for ; Sat, 9 Oct 2004 10:18:24 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i99HIZNH003715 for ; Sat, 9 Oct 2004 11:18:35 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5B00G7LUQYIY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 09 Oct 2004 11:18:35 -0600 (MDT) Received: from [192.168.1.24] ([204.174.35.171]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5B00KWZUQY3Q@mail.sun.net> for atom-syntax@imc.org; Sat, 09 Oct 2004 11:18:34 -0600 (MDT) Date: Sat, 09 Oct 2004 10:18:49 -0700 From: Tim Bray Subject: The link discussion To: Atom Syntax Message-id: <491E4F30-1A17-11D9-8692-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT It's pretty obvious we've got some serious work in front of us getting to a consensus position. I'd welcome meta-discussion suggestions as to how we might focus and move the discussion towards convergence. -Tim From owner-atom-syntax@mail.imc.org Sat Oct 9 13:29:22 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 NAA27222 for ; Sat, 9 Oct 2004 13:29: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 i99HMjiq074948; Sat, 9 Oct 2004 10:22:45 -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 i99HMj7p074947; Sat, 9 Oct 2004 10:22:45 -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 i99HMjfI074936 for ; Sat, 9 Oct 2004 10:22:45 -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 <2004100917225101300c1tome>; Sat, 9 Oct 2004 17:22:51 +0000 Date: Sat, 9 Oct 2004 11:22:50 -0600 Subject: Re: rel values 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: <41681A89.8070107@franklinmint.fm> Message-Id: 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 Saturday, October 9, 2004, at 11:06 AM, Robert Sayre wrote: > Antone Roundy wrote: >> On Saturday, October 9, 2004, at 10:16 AM, Robert Sayre wrote: >>> The default behavior associated with a link is the retrieval of >>> another Web resource."[0] >>> >>> In other words, if you don't want it retrieved, don't put it in a >>> link. >> I don't think this is quite narrow enough. I think should be >> used to retrieve a primary resource. By "primary resource" I mean >> for example, an HTML page. The HTML page itself may contain pointers >> to stylesheets, images, etc., which will also be retrieved, but >> which, in that context, are not the primary resources. That's not to >> say that those other resources couldn't, in some other context, be >> primary resources. In such a context, it would be appropriate for >> to point to them. > > Hmmm. I don't think I understand the distinction you are trying to > make. Perhaps you mean resources that would be the focus of a primary > viewing window? I don't think requirements on UA behavior are > in-bounds here.[0] Let me give another example. In an HTML page, points to something the publisher intends to have traversed in response to explicit user interaction, ie clicking. points to a resource that the publisher intends to have loaded automatically and embedded into the presentation of the HTML that contains it. points to a resource that the publisher intends to have loaded automatically and used to guide the presentation of the HTML that contains it. html:a -> atom:link. html:img -> something else. html:link[@rel="stylesheet"] -> something else. > UAs can make that decision based on type attributes, HEAD requests, > etc. Not by my thinking. Note the distinction between the following: Photo of Puppies Photo of Puppies From owner-atom-syntax@mail.imc.org Sat Oct 9 13:46: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 NAA28570 for ; Sat, 9 Oct 2004 13:46: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 i99HaY0O076505; Sat, 9 Oct 2004 10:36: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 i99HaYD8076504; Sat, 9 Oct 2004 10:36:34 -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 i99HaY7J076497 for ; Sat, 9 Oct 2004 10:36:34 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGL98-0006g7-If; Sat, 09 Oct 2004 17:36:42 +0000 Message-ID: <416821AD.8000509@franklinmint.fm> Date: Sat, 09 Oct 2004 13:36:45 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: rel values References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > html:a -> atom:link. html:img -> > something else. html:link[@rel="stylesheet"] -> something else. > html:img --> this is more generally called "inclusion". We let you do it. Once, maybe. Content@src. html:link[@rel="stylesheet"] --> 1.) broken, 2.) we don't have it >> UAs can make that decision based on type attributes, HEAD requests, etc. > > > Not by my thinking. Note the distinction between the following: > > Photo of Puppies > Photo of Puppies > atom:link is analogous to the anchor, but it has no presentation context. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 9 14:28:26 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 OAA00568 for ; Sat, 9 Oct 2004 14:28:26 -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 i99IJ4fl079117; Sat, 9 Oct 2004 11:19:04 -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 i99IJ4qI079116; Sat, 9 Oct 2004 11:19:04 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99IJ3CK079110 for ; Sat, 9 Oct 2004 11:19:04 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so80534rnk for ; Sat, 09 Oct 2004 11:19:08 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr679350rnh; Sat, 09 Oct 2004 11:19:08 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 11:19:08 -0700 (PDT) Message-ID: <1f2ed5cd041009111916fd5c58@mail.gmail.com> Date: Sat, 9 Oct 2004 20:19:08 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: meta-issue: arbitrary relationships required? Cc: Atom Syntax In-Reply-To: <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 09 Oct 2004 10:21:14 -0700, Tim Bray wrote: > > On Oct 9, 2004, at 9:30 AM, Danny Ayers wrote: > > as long as there is still a uniform means of defining > > arbitrary relationships between Atom resources and other resources. > > Is this a requirement for Atom? Yes, I believe it is, and most definitely should be. I suggest that it's not. I'd be > interested in hearing arguments from prior syndication art or from our > charter. -Tim The charter says: [[ The format must be able to represent additional information in an user-extensible manner. ... The Working Group will also take steps to ensure interoperability, by. ..describing how one migrates from the various RSS versions to the Atom syndication feed format. ]] The latter aspect is probably most significant in this discussion. You can add information to an RSS 1.0 feed featuring arbitrary relationships (properties). Producers and consumers that support RSS 1.0's model can uniformly interpret that information. A system migrated to Atom without support of this kind would lose a significant facility. Prior syndication art - RSS 1.0 fully supports it, e.g. there's a WordPress plugin to add terms from FOAF to give more info re. topics, authors etc: http://www.wasab.dk/morten/blog/feed/rdf Nature makes extensive use of the PRISM vocabularies: http://npg.nature.com/npg/servlet/Content?data=xml/02_newsfeed.xml&style=xml/02_newsfeed.xsl It's true that most RSS 1.0 producers and consumers only support enough of RDF to be able to get the data into their application model (or simply display it). But one thing this shows is that total commitment to a model isn't needed - really simple tools can still produce and consume RSS 1.0, despite it being declared to be a difficult syntax by a lot of people. There are sophisticated RDF tools around, and their number is growing - all of them support RSS 1.0 out of the box. Atom will (hopefully) have a syntax that will be considered simple. There is no suggestion here that it should support a model like RDF, just some form of mechanism or convention that will allow it to do a reasonable proportion of what RSS 1.0 can do. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 14:37:07 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 OAA01015 for ; Sat, 9 Oct 2004 14:37: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 i99ITCgm079643; Sat, 9 Oct 2004 11:29: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 i99ITCF3079642; Sat, 9 Oct 2004 11:29:12 -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 i99ITCjC079632 for ; Sat, 9 Oct 2004 11:29:12 -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 <2004100918291801400riokce>; Sat, 9 Oct 2004 18:29:19 +0000 Date: Sat, 9 Oct 2004 12:29:18 -0600 Subject: Re: PaceLinkConstruct 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: Message-Id: <21726902-1A21-11D9-B794-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 Friday, October 8, 2004, at 10:15 PM, Antone Roundy wrote: > On Friday, October 8, 2004, at 01:16 PM, Antone Roundy wrote: >> I'm +1 on this, with the possible exception of @rev. > Revising my position--I breezed too quickly over the part about a > closed list of @rel values. -1 to that. +1 to moving the list of > values from the API spec to the format spec. +1 to the additional > @rel values--they all seem like reasonable additions. 0 to @rev. Oops, I'm re-revising my position. I would think the most logical way to indicate the target of updated.by, replaced.by, update, and replaces would be with an atom:id, which might not be dereferencable. comment might also be so, though it could also be a link to a feed of comments. So something other than seems like a better place for those. I'm afraid I'm now only +1 to moving the list of values from the API spec to the format spec, which is covered by PaceMoveLinkElement, so -1 to PaceLinkConstruct. @rev could be reintroduced in another proposal. From owner-atom-syntax@mail.imc.org Sat Oct 9 14:44: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 OAA01341 for ; Sat, 9 Oct 2004 14:44:13 -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 i99IWmS2079899; Sat, 9 Oct 2004 11:32: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 i99IWm84079898; Sat, 9 Oct 2004 11:32:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03.rdc-kc.rr.com (ms-smtp-03.rdc-kc.rr.com [24.94.166.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99IWkXa079890 for ; Sat, 9 Oct 2004 11:32:47 -0700 (PDT) (envelope-from csgallagher@wi.rr.com) Received: from xp1 (CPE-65-25-169-159.wi.rr.com [65.25.169.159]) by ms-smtp-03.rdc-kc.rr.com (8.12.10/8.12.7) with ESMTP id i99IWtjE005897 for ; Sat, 9 Oct 2004 13:32:56 -0500 (CDT) Message-Id: <200410091832.i99IWtjE005897@ms-smtp-03.rdc-kc.rr.com> Reply-To: From: "Clinton Gallagher" To: "'Atom-Syntax'" Subject: Copyright Prefixed Namespaces Date: Sat, 9 Oct 2004 13:32:54 -0500 Organization: METROmilwaukee MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSuGBzeE2uoBrUxRXO/5i9T0gnp1QAEzkxQ In-Reply-To: <416807E2.5090408@intertwingly.net> X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I hope this RFI does not get me called any names as they do in the rss-dev list and due to a simple matter of pressing time conflicts I must admit I have not studied Atom sufficiently to determine if Atom uses namespaces but remain compelled regardless to ask for comments regarding the use of copyright to protect one's use of prefixed namespaces. If this is not a matter of interest to this list I hope I can encourage those with well recognized 'names' to be so kind as to refer me to contemporaneous commentary that speaks to this issue explicitly. I have yet to be able to find a lawyer with sufficient experience with software development. <%= Clinton Gallagher From owner-atom-syntax@mail.imc.org Sat Oct 9 15:03:24 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 PAA02234 for ; Sat, 9 Oct 2004 15:03:23 -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 i99Ithar081285; Sat, 9 Oct 2004 11:55:43 -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 i99Ithd4081284; Sat, 9 Oct 2004 11:55:43 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99ItbU8081274; Sat, 9 Oct 2004 11:55:37 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200410091832.i99IWtjE005897@ms-smtp-03.rdc-kc.rr.com> References: <200410091832.i99IWtjE005897@ms-smtp-03.rdc-kc.rr.com> Date: Sat, 9 Oct 2004 11:55:55 -0700 To: , "'Atom-Syntax'" From: Paul Hoffman / IMC Subject: Re: Copyright Prefixed Namespaces 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 1:32 PM -0500 10/9/04, Clinton Gallagher wrote: >I hope this RFI does not get me called any names as they do in the rss-dev >list and due to a simple matter of pressing time conflicts I must admit I >have not studied Atom sufficiently to determine if Atom uses namespaces but >remain compelled regardless to ask for comments regarding the use of >copyright to protect one's use of prefixed namespaces. No name-calling, but an explicit statement that "this is out of scope for the development of Atom". If you want advice about using laws to protect something, you really should pay a lawyer. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Oct 9 15:19: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 PAA03945 for ; Sat, 9 Oct 2004 15:19: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 i99JATKJ082148; Sat, 9 Oct 2004 12:10:29 -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 i99JATNg082147; Sat, 9 Oct 2004 12:10:29 -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 i99JASJV082141 for ; Sat, 9 Oct 2004 12:10:29 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGMbx-0002Vg-OJ; Sat, 09 Oct 2004 19:10:33 +0000 Message-ID: <416837AD.3040504@franklinmint.fm> Date: Sat, 09 Oct 2004 15:10:37 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Tim Bray , Atom Syntax Subject: Re: meta-issue: arbitrary relationships required? References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> <1f2ed5cd041009111916fd5c58@mail.gmail.com> In-Reply-To: <1f2ed5cd041009111916fd5c58@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > Producers and consumers that support RSS > 1.0's model can uniformly interpret that information. A system > migrated to Atom without support of this kind would lose a significant > facility. > The kicker here is that consumers don't support RSS1.0's model because it isn't helpful. The tricky part of supporting an extension is writing the handler. > Prior syndication art - RSS 1.0 fully supports it, e.g. there's a > WordPress plugin to add terms from FOAF to give more info re. topics, > authors etc: > > http://www.wasab.dk/morten/blog/feed/rdf > > http://npg.nature.com/npg/servlet/Content?data=xml/02_newsfeed.xml&style=xml/02_newsfeed.xsl > > Atom will (hopefully) have a syntax that will be considered simple. > There is no suggestion here that it should support a model like RDF, > just some form of mechanism or convention that will allow it to do a > reasonable proportion of what RSS 1.0 can do. > Show me an example of a client doing something useful with the extensions in those two feeds. Then, tell me why it would be impossible or harder in Atom. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 9 15:30:40 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 PAA04715 for ; Sat, 9 Oct 2004 15:30:39 -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 i99JM5p2083281; Sat, 9 Oct 2004 12:22:05 -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 i99JM5S8083280; Sat, 9 Oct 2004 12:22:05 -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 i99JM5EO083267 for ; Sat, 9 Oct 2004 12:22:05 -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 <2004100919221101300c97p7e>; Sat, 9 Oct 2004 19:22:11 +0000 Date: Sat, 9 Oct 2004 13:22:10 -0600 Subject: Re: The link discussion 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: <491E4F30-1A17-11D9-8692-000A95A51C9E@sun.com> Message-Id: <842DE1F0-1A28-11D9-B794-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 Saturday, October 9, 2004, at 11:18 AM, Tim Bray wrote: > It's pretty obvious we've got some serious work in front of us getting > to a consensus position. I'd welcome meta-discussion suggestions as > to how we might focus and move the discussion towards convergence. Of the proposals under discussion, PaceDateOfSubject is obviously not part of this question. PaceLinkTitle is also an independent issue. That leaves us with the following to address: PaceLinkAttrDefaults, PaceLinkConstruct, PaceLinkDelicious, PaceLinkParent, PaceLinkPurpose, PaceLinkRelMechanism, PaceReplaceLinkElement ...and perhaps the follow new proposals created in response to the current discussion: PaceRelationshipConstruct, PaceConstructAttribute, PaceLinkRelPrefix Here's a way to group the above: Extensibility: PaceLinkRelMechanism, PaceRelationshipConstruct, PaceConstructAttribute, PaceLinkRelPrefix Specific @rel values (or element names, if PaceReplaceLinkElement is adopted): PaceLinkAttrDefaults, PaceLinkConstruct, PaceLinkDelicious, PaceLinkParent Other: PaceLinkPurpose, PaceReplaceLinkElement Here are two options we could start by choosing between, and the next steps that would arise from each. 1) Allow Link Constructs (I'm purposely not saying "the link element" both here and below) to point to various sorts of things rather than tightening it up as suggested in PaceLinkPurpose -- don't use Link Constructs as a "partially understandable" extension point * close PaceLinkPurpose, as well as everything listed above under "Extensibility", which I don't think has any value without a tighter definition of Link Constructs * continue discussion of PaceReplaceLinkElement and everything listed under "Specific @rel values" 2) Tighten the definition of the Link Construct in a manner akin to PaceLinkPurpose * refine the language of PaceLinkPurpose and incorporate it * close PaceLinkConstruct and PaceLinkParent (the additions proposed in both, to refer to atom:entries, should probably be done using atom:id, which may not be dereferencable, so they would no longer belong in any Link Construct.) * continue to discuss PaceReplaceLinkElement, PaceLinkAttrDefaults, PaceLinkDelicious, and everything listed under "Extensibility" The first option simplifies the discussion more, but I think it's the wrong way to go. If we choose the second option, I'd suggest attacking the "Extensibility" proposals next while we're still fired up for the fight rather than postponing this core question yet again, and leaving the other three till after that. PaceReplaceLinkElement is a similarly big question, but I think it will be easier to address after making a decision regarding extensibility. From owner-atom-syntax@mail.imc.org Sat Oct 9 18:09: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 SAA12735 for ; Sat, 9 Oct 2004 18:09:13 -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 i99M2ROQ091601; Sat, 9 Oct 2004 15:02:27 -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 i99M2R7l091600; Sat, 9 Oct 2004 15:02:27 -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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99M2Q17091594 for ; Sat, 9 Oct 2004 15:02:27 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so84432rnk for ; Sat, 09 Oct 2004 15:02:39 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr726459rnh; Sat, 09 Oct 2004 15:02:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 15:02:39 -0700 (PDT) Message-ID: <1f2ed5cd04100915027479a22a@mail.gmail.com> Date: Sun, 10 Oct 2004 00:02:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: meta-issue: arbitrary relationships required? Cc: Tim Bray , Atom Syntax In-Reply-To: <1f2ed5cd0410091500742114cd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> <1f2ed5cd041009111916fd5c58@mail.gmail.com> <416837AD.3040504@franklinmint.fm> <1f2ed5cd0410091500742114cd@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry, forgot the links: BrownSauce: http://jena.hpl.hp.com:3030/brownsauce/index.html Source: http://www.nature.com/nature/journal/v431/n7009/rss.rdf Resource: http://dx.doi.org/10.1038/431613a Source: http://www.wasab.dk/morten/blog/feed/rdf Resource: http://www.wasab.dk/morten/blog/archives/2004/09/30/aggregating-and-archiving-rss-items On Sun, 10 Oct 2004 00:00:50 +0200, Danny Ayers wrote: > On Sat, 09 Oct 2004 15:10:37 -0400, Robert Sayre wrote: > > Danny Ayers wrote: > > > > > Producers and consumers that support RSS > > > 1.0's model can uniformly interpret that information. A system > > > migrated to Atom without support of this kind would lose a significant > > > facility. > > > > > > > The kicker here is that consumers don't support RSS1.0's model because > > it isn't helpful. The tricky part of supporting an extension is writing > > the handler. > > Several syndication-oriented consumers do support RSS 1.0's model, and > all RDF tools (that support the standard interchange format) support > RSS 1.0. There are lots of them (see > http://www.ilrt.bris.ac.uk/discovery/rdf/resources/#sec-tools). > > The model can be extremely useful, especially when you want to mix > data from different domains. Urchin is a pretty good example: > http://urchin.sourceforge.net/docs/Design.html > > Matt Biddulph has some good RSS+FOAF material: > http://www.hackdiary.com/archives/000020.html > http://www.hackdiary.com/projects/chumpologica/ > > > Show me an example of a client doing something useful with the > > extensions in those two feeds. > > Ok, try BrownSauce - it's not exactly a wonderful visualization (it's > designed for displaying completely arbitrary data), but it'll do for > demonstration purpose. Links below. > > One of the displayed lines from the rss:item in the Nature feed is: > Source: Nature 431, 613 (2004) > > Part of the display of the rss:item from Morten's feed is: > # topic: > * RSS > * Title: RSS > * page: RSS > > Then, tell me why it would be impossible > > or harder in Atom. > > The displays are based on a interpretation of the data based on the > semantics encoded in RDF/XML, specifically how a relationship defined > in an external namespace is associated between a resource in the RSS > feed and other data/resources. Atom has no such mechanism. The tool is > rendering the data consistently across all (unknown) relationships, > potentially expressed in different syntax styles, but following the > rules of RSS 1.0. Can't be done in Atom. > > I know it's not exactly a mindblowing display, I'll see what I can > find with a bit more glitz. (Using the chumpalogica to aggregate from > the feeds and then doing a FOAF-based query on the data in Redland > might be nice...) But it does what you asked. > > > There seems to be a tendency around these parts to take a very narrow > view of what a tool that uses syndication formats should be like. This > being based on the implementations that have appeared in the last year > or so - ok, not too surprising considering desktop aggregators have > only been around for maybe 3 years. But all due respect to their > developers, but the current versions of BlogLines and RssBandit might > be very useful but they aren't the end of the story, they're the > beginning. > > Kind of reminds me of when, years back, my mother got herself an > Amstrad Word Processor. Took me ages to convince her it was a > computer. > > > > > Cheers, > Danny. > > -- > > http://dannyayers.com > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 18:13:48 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 SAA13346 for ; Sat, 9 Oct 2004 18:13:47 -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 i99M0nQo091509; Sat, 9 Oct 2004 15:00:49 -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 i99M0ngB091508; Sat, 9 Oct 2004 15:00:49 -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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i99M0m2v091501 for ; Sat, 9 Oct 2004 15:00:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so84413rnk for ; Sat, 09 Oct 2004 15:00:51 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr715663rnf; Sat, 09 Oct 2004 15:00:50 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 9 Oct 2004 15:00:50 -0700 (PDT) Message-ID: <1f2ed5cd0410091500742114cd@mail.gmail.com> Date: Sun, 10 Oct 2004 00:00:50 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: meta-issue: arbitrary relationships required? Cc: Tim Bray , Atom Syntax In-Reply-To: <416837AD.3040504@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> <1f2ed5cd041009111916fd5c58@mail.gmail.com> <416837AD.3040504@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 09 Oct 2004 15:10:37 -0400, Robert Sayre wrote: > Danny Ayers wrote: > > > Producers and consumers that support RSS > > 1.0's model can uniformly interpret that information. A system > > migrated to Atom without support of this kind would lose a significant > > facility. > > > > The kicker here is that consumers don't support RSS1.0's model because > it isn't helpful. The tricky part of supporting an extension is writing > the handler. Several syndication-oriented consumers do support RSS 1.0's model, and all RDF tools (that support the standard interchange format) support RSS 1.0. There are lots of them (see http://www.ilrt.bris.ac.uk/discovery/rdf/resources/#sec-tools). The model can be extremely useful, especially when you want to mix data from different domains. Urchin is a pretty good example: http://urchin.sourceforge.net/docs/Design.html Matt Biddulph has some good RSS+FOAF material: http://www.hackdiary.com/archives/000020.html http://www.hackdiary.com/projects/chumpologica/ > Show me an example of a client doing something useful with the > extensions in those two feeds. Ok, try BrownSauce - it's not exactly a wonderful visualization (it's designed for displaying completely arbitrary data), but it'll do for demonstration purpose. Links below. One of the displayed lines from the rss:item in the Nature feed is: Source: Nature 431, 613 (2004) Part of the display of the rss:item from Morten's feed is: # topic: * RSS * Title: RSS * page: RSS Then, tell me why it would be impossible > or harder in Atom. The displays are based on a interpretation of the data based on the semantics encoded in RDF/XML, specifically how a relationship defined in an external namespace is associated between a resource in the RSS feed and other data/resources. Atom has no such mechanism. The tool is rendering the data consistently across all (unknown) relationships, potentially expressed in different syntax styles, but following the rules of RSS 1.0. Can't be done in Atom. I know it's not exactly a mindblowing display, I'll see what I can find with a bit more glitz. (Using the chumpalogica to aggregate from the feeds and then doing a FOAF-based query on the data in Redland might be nice...) But it does what you asked. There seems to be a tendency around these parts to take a very narrow view of what a tool that uses syndication formats should be like. This being based on the implementations that have appeared in the last year or so - ok, not too surprising considering desktop aggregators have only been around for maybe 3 years. But all due respect to their developers, but the current versions of BlogLines and RssBandit might be very useful but they aren't the end of the story, they're the beginning. Kind of reminds me of when, years back, my mother got herself an Amstrad Word Processor. Took me ages to convince her it was a computer. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 9 18:48:28 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 SAA15193 for ; Sat, 9 Oct 2004 18:48:28 -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 i99MfwaI093939; Sat, 9 Oct 2004 15:41:58 -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 i99MfwhR093938; Sat, 9 Oct 2004 15:41:58 -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 i99MfuAH093932 for ; Sat, 9 Oct 2004 15:41:57 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.4]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGPue-00023K-VE; Sat, 09 Oct 2004 22:42:05 +0000 Message-ID: <41686940.5030104@franklinmint.fm> Date: Sat, 09 Oct 2004 18:42:08 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Tim Bray , Atom Syntax Subject: Re: meta-issue: arbitrary relationships required? References: <20041009153858.79660.qmail@web41210.mail.yahoo.com> <41680ECA.9050107@franklinmint.fm> <1f2ed5cd041009093056b0fe54@mail.gmail.com> <9F99AF5A-1A17-11D9-8692-000A95A51C9E@sun.com> <1f2ed5cd041009111916fd5c58@mail.gmail.com> <416837AD.3040504@franklinmint.fm> <1f2ed5cd0410091500742114cd@mail.gmail.com> In-Reply-To: <1f2ed5cd0410091500742114cd@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > The displays are based on a interpretation of the data based on the > semantics encoded in RDF/XML, specifically how a relationship defined > in an external namespace is associated between a resource in the RSS > feed and other data/resources. Atom has no such mechanism. Oh, ok. You want a place to put properties. That makes sense. Here is my proposal: 1.) Properties of atom:entry are child elements of atom:entry 2.) Properties of atom:feed go in atom:head 3.) There is no other place to put extension elements in Atom 1.0 Note that these extensions can be arbitrarily complex (you can even use RDF :). Basically, this means none of the Atom-defined "Common Atom Constructs" are extensible, although atom:content has a "blob" property. Off-the-top-of-my-head methods for dealing with existing "Common Atom Constructs": 1.) Content Construct You have a "blob". Use it if you have "special" content. A prop on atom:entry would probably do otherwise. 2.) Person Construct "But I want to put FOAF in!" No, you want to relate FOAF information to this entry AND a person. If you have general person information, it would be bad to boxcar lots of personal info in an entry. If it relates to the entry, it can be a prop of entry. If you need to relate extension data to the Person Construct, that construct provides a handy URI. Refer to it. 3.) Date Construct Don't extend this. Add a new kind of date. 4.) Identity Constructs Don't extend this. 5.) Text Constructs (coming soon to a spec near you!) Don't extend this. 6.) Link Constructs "But I want an extra attribute!" No, you want to enclose the Link Construct in an extension element. > > There seems to be a tendency around these parts to take a very narrow > view of what a tool that uses syndication formats should be like... No, there is a very narrow view of the type of information that is useful in this format, especially in core. General-purpose assertions are not demonstrably useful in this space, but taking steps to make sure they work seems reasonable. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 9 20:25: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 UAA18636 for ; Sat, 9 Oct 2004 20:25:41 -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 i9A0GcR0000268; Sat, 9 Oct 2004 17:16:38 -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 i9A0Gc9p000267; Sat, 9 Oct 2004 17:16:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9A0GcsF000259 for ; Sat, 9 Oct 2004 17:16:38 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041010001646.82950.qmail@web41205.mail.yahoo.com> Received: from [24.18.138.143] by web41205.mail.yahoo.com via HTTP; Sat, 09 Oct 2004 17:16:46 PDT Date: Sat, 9 Oct 2004 17:16:46 -0700 (PDT) From: Dare Obasanjo Subject: Re: meta-issue: arbitrary relationships required? To: Robert Sayre , Danny Ayers Cc: Tim Bray , Atom Syntax In-Reply-To: <41686940.5030104@franklinmint.fm> 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: --- Robert Sayre wrote: > > Danny Ayers wrote: > > > > > The displays are based on a interpretation of the > data based on the > > semantics encoded in RDF/XML, specifically how a > relationship defined > > in an external namespace is associated between a > resource in the RSS > > feed and other data/resources. Atom has no such > mechanism. > > Oh, ok. You want a place to put properties. That > makes sense. Here is my > proposal: > > 1.) Properties of atom:entry are child elements of > atom:entry > 2.) Properties of atom:feed go in atom:head > 3.) There is no other place to put extension > elements in Atom 1.0 > > Note that these extensions can be arbitrarily > complex (you can even use > RDF :). > > Basically, this means none of the Atom-defined > "Common Atom Constructs" > are extensible, although atom:content has a "blob" > property. I almost agree with this entire email 100% I'm partial to allowing some form of extensibility in link constructs IFF a clear and concise definition of what it means to be 'link' makes it into the spec. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sun Oct 10 06:50:19 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 GAA01535 for ; Sun, 10 Oct 2004 06:50:19 -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 i9AAdfKX044957; Sun, 10 Oct 2004 03:39: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 i9AAdfUT044956; Sun, 10 Oct 2004 03:39:41 -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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AAdd4X044912 for ; Sun, 10 Oct 2004 03:39:39 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so96235rnk for ; Sun, 10 Oct 2004 03:39:29 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr857081rnf; Sun, 10 Oct 2004 03:39:29 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sun, 10 Oct 2004 03:39:29 -0700 (PDT) Message-ID: <1f2ed5cd04101003391b556eaf@mail.gmail.com> Date: Sun, 10 Oct 2004 12:39:29 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: meta-issue: arbitrary relationships required? Cc: Robert Sayre , Tim Bray , Atom Syntax In-Reply-To: <20041010001646.82950.qmail@web41205.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41686940.5030104@franklinmint.fm> <20041010001646.82950.qmail@web41205.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 9 Oct 2004 17:16:46 -0700 (PDT), Dare Obasanjo wrote: > > --- Robert Sayre wrote: > > Oh, ok. You want a place to put properties. That > > makes sense. Here is my > > proposal: > > > > 1.) Properties of atom:entry are child elements of > > atom:entry > > 2.) Properties of atom:feed go in atom:head > > 3.) There is no other place to put extension > > elements in Atom 1.0 > > > > Note that these extensions can be arbitrarily > > complex (you can even use > > RDF :). Broad strokes, but I think the kind of extension constraints I believe Atom needs could be provided this way. Some details probably need to be taken into account, things like the conceptual role of attributes, so core syntax can be seen to be consistent with core+extensions. But yeah, I reckon this is defintiely in the right direction. I'm not sure either way, but this part seems a bit quirky/capricious/irrational/inexplicable (the thesaurus couldn't give me the exact word I was after) : > > Basically, this means none of the Atom-defined > > "Common Atom Constructs" > > are extensible, Why shouldn't they be? If for example the information relates to the date of an entry (e.g. the value in the Indian Calendar), wouldn't it make sense to associate this with the Date Construct, and include it inside/alongside? Referring back to the use of FOAF in RSS 1.0, one option is in the rss:item (corresponding to the atom:entry, which kind-of follows the approach you describe - example here: http://feeds.feedburner.com/BenHammersleysDangerousPrecedent Contributors are placed inside the entry, but additional data about the person is placed *inside* that. It works, but I'm not convinced this is near the ideal. If there's already a clearly demarcated place in the format for person-related details (i.e. the Person Construct), should n't person-related extension stuff go in there? Ok, if all the subjects of "Common Atom Constructs" have URIs, then as you say the additional info can be asserted elsewhere. But where? Placing it in a content blob seems highly inappropriate. Could/should we e.g. put details of the contributors (expressed in non-Atom language) in the head? This could probably do with passing onto danbri and the FOAFnauts for comment, if your suggestion is adequate for FOAF then it'll probably cover anything anyone cares to throw at it. > I almost agree with this entire email > 100% Which is an unusual and promising sign ;-) > I'm partial to allowing some form of extensibility in > link constructs IFF a clear and concise definition of > what it means to be 'link' makes it into the spec. Ditto, ditto. I think the sense of 'link' intended in most of the discussions so far can be seen as a special case of the more general properties Robert has laid out. Cheers, Danny. From owner-atom-syntax@mail.imc.org Sun Oct 10 08:27:23 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 IAA06990 for ; Sun, 10 Oct 2004 08:27:22 -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 i9ACJcV8060374; Sun, 10 Oct 2004 05:19:38 -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 i9ACJcwc060373; Sun, 10 Oct 2004 05:19:38 -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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ACJZWB060361 for ; Sun, 10 Oct 2004 05:19:35 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so97269rnk for ; Sun, 10 Oct 2004 05:19:29 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr868322rnf; Sun, 10 Oct 2004 05:19:29 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sun, 10 Oct 2004 05:19:29 -0700 (PDT) Message-ID: <1f2ed5cd041010051961824df0@mail.gmail.com> Date: Sun, 10 Oct 2004 14:19:29 +0200 From: Danny Ayers Reply-To: Danny Ayers To: rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com Subject: Atom and RDF Cc: rss-dev@yahoogroups.com, atom-syntax@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Issues of extensibility and language interop for the Atom Syndication Format [1] have been bouncing around the Atom (IETF) group from day one. Right now I think discussions may (again) be at a point where input from the RDF/FOAF community could be helpful. The Atom charter [2] says: [[ The format must be able... ...to represent additional information in an user-extensible manner. ... The Working Group will also take steps to ensure interoperability, by - ...describing how one migrates from the various RSS versions to the Atom syndication feed format. ]] There are various dialects in use, but generally RSS syndication material comes under the umbrella of either RSS 1.0 or RSS 2.0 (the version numbers are only of political significance). RSS 1.0 [3] is defined as an RDF vocabulary, with a constrained subset of RDF/XML as its exchange syntax (over HTTP), so there's clearly some overlap with RDF efforts. RSS 1.0 extensions must follow the constraints of RDF. So RDF is at least potentially a factor in Atom's user-extensibility and must be a consideration when format migration is under discussion. RSS 2.0 [4] is defined as a 'simple' XML format. It hasn't got a namespace itself, though any material in other XML namespaces can appeared in the document and be called an extension. Most syndication tools (for publishing and reading) support both formats. Most syndication tools only support enough of the RDF model to be able to extract the syndication-domain data (there are notable exceptions, and of course virtually all RDF tools can consume & process RSS 1.0 out of the box). Developers of syndication tools tend to have expertise with regular expressions. Aside from all else, there is (loosely) a polarization of opinion among Atom WG members on how it should tackle extension and interop issues, this being roughly parallel to that of RSS 1.0 vs. RSS 2.0. One pole is probably most easily expressed by saying Atom should've been defined as an RDF/OWL vocabulary and the exchange syntax made compatible with RDF/XML. The other pole is that Atom Core should be totally bolted down, and extensions should simply be partitioned off using XML namespaces. There would be no systematic approach to those extensions, anything could go anywhere. I would guess that group consensus generally leans towards the latter pole. (Come to think of it, probably everyone agrees with the bolted-down core part). In [5] Robert Sayre describes an option for applying potentially arbitrary properties to Atom entries in a uniform fashion, which may be enough (given a bit of polish) to disambiguate extensions into RDF-compatible statements. His suggestion hasn't brought immediate condemnation from the core+namespace-only camp. Which is promising. But how workable does this seem from the RDF point of view? To me it looks like the kind of structural constraint suggested will go a long way towards allowing extraction of viable RDF from fairly arbitrarily extended Atom documents e.g. using XSLT -> RDF/XML. All the usual suspects like FOAF and DC could be used to make richer Atom documents, without compromising the core format. Does that sound about right? Or wouldn't it work? Or is there a better approach to RDF-compatibility that wouldn't worry the simple-XML camp? Why does it matter? I think RDF potentially stands to gain quite a lot from Atom, in the form of a relatively lightweight but versatile and thoroughly spec'ed transport (and editing protocol) which is likely to gain widespread deployment. Atom can gain potentially a lot from RDF, up front for its intuitions into modelling on the Web and longer term through compatibility with (and adoption by) RDF-based systems. Then everyone gains when all these systems are joined together... Cheers, Danny. [1] http://www.intertwingly.net/wiki/pie/FrontPage [2] http://www.ietf.org/html.charters/atompub-charter.html [3] http://purl.org/rss/1.0/spec [4] http://blogs.law.harvard.edu/tech/rss [5] http://www.imc.org/atom-syntax/mail-archive/msg10481.html -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 10 09:27: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 JAA09890 for ; Sun, 10 Oct 2004 09:27: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 i9ADK1OE064914; Sun, 10 Oct 2004 06:20:01 -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 i9ADK15e064913; Sun, 10 Oct 2004 06:20:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ADK0Lt064849 for ; Sun, 10 Oct 2004 06:20:00 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9ADIds6005832 for ; Sun, 10 Oct 2004 14:18:45 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1f2ed5cd04100909014d2bef6b@mail.gmail.com> References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <41680228.7040401@franklinmint.fm> <1f2ed5cd04100909014d2bef6b@mail.gmail.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-995519360; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: rel values Date: Sun, 10 Oct 2004 14:18:39 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-995519360 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 9 Oct 2004, at 5:01 pm, Danny Ayers wrote: > On Sat, 09 Oct 2004 11:22:16 -0400, Robert Sayre > wrote: >> >> Graham wrote: >> >>> Motion put to the floor of the house: >>> >>> There is no practicable way to make @rel values extensible. >>> > > Why aren't URIs practicable? I didn't say they weren't. If you think they are, argue against the motion using them as an example. (btw Is there a Pace for them?) Graham --Apple-Mail-2-995519360 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDEwMTMxODQwWjAjBgkqhkiG9w0BCQQxFgQUtC67AHwYT8dG95Q/guohFBuh VkwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAPFsiuBMUv2qxquAL0IyqapNW zSCNKQkckMaYPXMCOqZyBv+DuIPXa7JHz1Vvcw8HURNfeOQKmFPf2iMjHd4DqKgDoT7y+s2vBtcH ArcN1d5zeUN3blZdfHorPHMi8J3wxDEtF+mdSzHC8bgL0FOKS0/+84oaDbi6kEdYhZvZaugTlQS3 cdFQRZ4mbM3c916ijKxNTyZ2Z8y6/ls33fIzTtmg9s1RRq+HUawTKtl5a//r3zraKQo+5/IdnzOe DbsANofwb8+YjCZvxsMrAL2cx/oe4ByGYQR5zE6rvjOmNBjcUhh7IHH0S4nqw+SCK7IBLZ+7geM7 2mLKwWm4i5JPawAAAAAAAA== --Apple-Mail-2-995519360-- From owner-atom-syntax@mail.imc.org Sun Oct 10 11:25: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 LAA18624 for ; Sun, 10 Oct 2004 11:25: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 i9AFEsEi072258; Sun, 10 Oct 2004 08:14:54 -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 i9AFEsdo072257; Sun, 10 Oct 2004 08:14:54 -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 i9AFErgd072248 for ; Sun, 10 Oct 2004 08:14:54 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2D6A77C2F0; Sun, 10 Oct 2004 17:14:18 +0200 (CEST) To: "Danny Ayers" Cc: Atom-Syntax Subject: Re: PaceReplaceLinkElement References: <1f2ed5cd0410081217ed68986@mail.gmail.com> Message-ID: Date: Sun, 10 Oct 2004 17:18:13 +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: <1f2ed5cd0410081217ed68986@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 8 Oct 2004 21:17:11 +0200, Danny Ayers wrote: > > might be better expressed as > > +1. I agree. Prefixing all methods with 'service-' would almost make 'service' an own namespace, only it's not. So pushing the method of the element out into an attribute is natural, although we won't expect to extend this very much. It's just clearer and neater that way. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sun Oct 10 11:36: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 LAA19335 for ; Sun, 10 Oct 2004 11:36:45 -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 i9AFTtge073184; Sun, 10 Oct 2004 08:29: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 i9AFTtYb073183; Sun, 10 Oct 2004 08:29:55 -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 i9AFTs3K073174 for ; Sun, 10 Oct 2004 08:29:54 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.102]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGfdv-0002O4-Ol; Sun, 10 Oct 2004 15:29:51 +0000 Message-ID: <41695572.3050204@franklinmint.fm> Date: Sun, 10 Oct 2004 11:29:54 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom Syntax Subject: Re: PaceReplaceLinkElement References: <1f2ed5cd0410081217ed68986@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Fri, 8 Oct 2004 21:17:11 +0200, Danny Ayers > wrote: > >> >> might be better expressed as >> >> > > > +1. I agree. Prefixing all methods with 'service-' would almost make > 'service' an own namespace, only it's not. So pushing the method of the > element out into an attribute is natural, although we won't expect to > extend this very much. It's just clearer and neater that way. > -1. Let's not assert which methods are allowed on these resources. The element should describe what the resource is, not what methods are allowed. Use OPTIONS for that. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Oct 10 11:37:27 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 LAA19439 for ; Sun, 10 Oct 2004 11:37:26 -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 i9AFT3hL073134; Sun, 10 Oct 2004 08:29:03 -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 i9AFT3Kl073133; Sun, 10 Oct 2004 08:29:03 -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 ESMTP id i9AFT2rj073125 for ; Sun, 10 Oct 2004 08:29:03 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so100339rnk for ; Sun, 10 Oct 2004 08:29:02 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr910751rnf; Sun, 10 Oct 2004 08:29:02 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sun, 10 Oct 2004 08:29:02 -0700 (PDT) Message-ID: <1f2ed5cd04101008297f2ff85c@mail.gmail.com> Date: Sun, 10 Oct 2004 17:29:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: rel values Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041008173843.10756.qmail@web41213.mail.yahoo.com> <41680228.7040401@franklinmint.fm> <1f2ed5cd04100909014d2bef6b@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 10 Oct 2004 14:18:39 +0100, Graham wrote: > On 9 Oct 2004, at 5:01 pm, Danny Ayers wrote: > > > On Sat, 09 Oct 2004 11:22:16 -0400, Robert Sayre > > wrote: > >> > >> Graham wrote: > >> > >>> Motion put to the floor of the house: > >>> > >>> There is no practicable way to make @rel values extensible. > >>> > > > > Why aren't URIs practicable? > > I didn't say they weren't. If you think they are, argue against the > motion using them as an example. Hmm, strange process thing, but a motion is usually a proposal put to the vote. The above appears to be an (unsubstantiated, controversial) statement. > (btw Is there a Pace for them?) There is now: http://www.intertwingly.net/wiki/pie/PaceLinkRelUri But it might not be needed if the current link/relationship branches prove fruitful. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 10 11:38:56 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 LAA19585 for ; Sun, 10 Oct 2004 11:38:55 -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 i9AFX8m0073388; Sun, 10 Oct 2004 08:33: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 i9AFX8uT073387; Sun, 10 Oct 2004 08:33:08 -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 i9AFX73w073381 for ; Sun, 10 Oct 2004 08:33:08 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf5ds.cable.mindspring.com ([24.215.149.188] helo=[192.168.1.102]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CGfgx-0002TV-Ng; Sun, 10 Oct 2004 15:32:59 +0000 Message-ID: <4169562E.9080605@franklinmint.fm> Date: Sun, 10 Oct 2004 11:33:02 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Dare Obasanjo , Tim Bray , Atom Syntax Subject: Re: meta-issue: arbitrary relationships required? References: <41686940.5030104@franklinmint.fm> <20041010001646.82950.qmail@web41205.mail.yahoo.com> <1f2ed5cd04101003391b556eaf@mail.gmail.com> In-Reply-To: <1f2ed5cd04101003391b556eaf@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [more assertions] Danny Ayers wrote: > On Sat, 9 Oct 2004 17:16:46 -0700 (PDT), Dare Obasanjo wrote: > >>--- Robert Sayre wrote: > > I'm not sure either way, but this part seems a bit > quirky/capricious/irrational/inexplicable (the thesaurus couldn't give > me the exact word I was after) : > E, all of the above. But, I still think it's the right thing to do. > >>>Basically, this means none of the Atom-defined >>>"Common Atom Constructs" >>>are extensible, > > > Why shouldn't they be? If for example the information relates to the > date of an entry (e.g. the value in the Indian Calendar), wouldn't it > make sense to associate this with the Date Construct, and include it > inside/alongside? I doubt you need to extend the Date Construct to do this. Show us an example. > > Referring back to the use of FOAF in RSS 1.0, one option is in the > rss:item (corresponding to the atom:entry, which kind-of follows the > approach you describe - example here: > > http://feeds.feedburner.com/BenHammersleysDangerousPrecedent > > Contributors are placed inside the entry, but additional data about > the person is placed *inside* that. It works, but I'm not convinced > this is near the ideal. If there's already a clearly demarcated place > in the format for person-related details (i.e. the Person Construct), > should n't person-related extension stuff go in there? > Atom extensibility is geared towards entries. Everything else should be crushingly simple and not extensible. FOAF data is not the same thing as atom:person. They are two vocabularies with similar goals, but they are not composable. If the FOAF standard was somewhere an IETF standard could cite it, it might be a good fit for Atom, but Atom doesn't need to provide general purpose person information. Worst case, everyone starts using FOAF and they have to duplicate a couple things. FOAF advocates don't appear to be bandwidth conservationists. > Ok, if all the subjects of "Common Atom Constructs" have URIs, They don't have URIs in the sense you're thinking of. The atom:entry is the end of the line. Things with URIs are located physically outside of the entry. > then as > you say the additional info can be asserted elsewhere. But where? > Placing it in a content blob seems highly inappropriate. Could/should > we e.g. put details of the contributors (expressed in non-Atom > language) in the head? > Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 11 05:11: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 FAA15872 for ; Mon, 11 Oct 2004 05:11: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 i9B8ujGi032081; Mon, 11 Oct 2004 01:56:45 -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 i9B8ujBQ032079; Mon, 11 Oct 2004 01:56:45 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9B8ui7D032055 for ; Mon, 11 Oct 2004 01:56:44 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so126522rnk for ; Mon, 11 Oct 2004 01:56:39 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr1138031rnf; Mon, 11 Oct 2004 01:56:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 11 Oct 2004 01:56:39 -0700 (PDT) Message-ID: <1f2ed5cd0410110156152795b9@mail.gmail.com> Date: Mon, 11 Oct 2004 10:56:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Possible use case: Auctions Cc: uldis.bojars@gmx.net Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A novel use of RSS that might make a good use case (or money-spinner) for Atom - eBay-style auctions: http://www.bidera.com/ Uldis Bojars has done some analysis of their feeds: http://captsolo.net/info/blog_a.php/2004/10/10/rss_in_auctions -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 11 06:16:07 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 GAA20337 for ; Mon, 11 Oct 2004 06:16: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 i9B9xWCv055897; Mon, 11 Oct 2004 02:59: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 i9B9xWVI055896; Mon, 11 Oct 2004 02:59:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9B9xU54055811 for ; Mon, 11 Oct 2004 02:59:31 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9B9uZBY013311; Mon, 11 Oct 2004 10:56:35 +0100 (BST) In-Reply-To: <41695572.3050204@franklinmint.fm> References: <1f2ed5cd0410081217ed68986@mail.gmail.com> <41695572.3050204@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-1069795161; protocol="application/pkcs7-signature" Message-Id: Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom Syntax From: Graham Subject: Re: PaceReplaceLinkElement Date: Mon, 11 Oct 2004 10:56:35 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-1069795161 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable PaceReplaceLinkElement needs to be updated slightly to reflect that=20 PaceServiceElement has been accepted, and thus the service elements are=20= no longer part of the link element. (I love how people around here will argue over anything) Graham On 10 Oct 2004, at 4:29 pm, Robert Sayre wrote: > > Asbj=F8rn Ulsberg wrote: >> On Fri, 8 Oct 2004 21:17:11 +0200, Danny Ayers=20 >> wrote: >>> >>> might be better expressed as >>> >>> >> +1. I agree. Prefixing all methods with 'service-' would almost make =20= >> 'service' an own namespace, only it's not. So pushing the method of=20= >> the element out into an attribute is natural, although we won't=20 >> expect to extend this very much. It's just clearer and neater that=20= >> way. > > -1. Let's not assert which methods are allowed on these resources. The=20= > element should describe what the resource is, not what methods are=20 > allowed. Use OPTIONS for that. > > Robert Sayre > --Apple-Mail-2-1069795161 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDExMDk1NjM1WjAjBgkqhkiG9w0BCQQxFgQUabCmc04ISJakr0SG1CBmkUZy ja4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAFUOmgkZRhdz4WeUfRvUEx8Os qdARVWyqQffujDYCMblXAOAMj024yAGdsDmVEWeIv+wCZsy1fdLSFHyJrkBCPN15XDpaLhRuYYDe gLvDn268zLCHreahvGByb03yEqGqDQZCX7dfdmoQcNbNt8HhieJ+se52k3GbxujyJEYmhkNzSQqh xaw4ZJ7SYUpji3QDp4MD1yZj2x65Mo3t9CuWCXi5INvGIEchIk7nMSk9RyBdMznJQIg4RM6zbKGY /267DwhH5lVXjnDl2bDk9mPN8cUf1nGs8rxyn/cOOiIVE0BfJYh2C2vo3G5ucAn3DmLD99C9Pufx EY0VT8VdUdjfigAAAAAAAA== --Apple-Mail-2-1069795161-- From owner-atom-syntax@mail.imc.org Mon Oct 11 10:44:38 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 KAA11485 for ; Mon, 11 Oct 2004 10:44:37 -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 i9BEYoF6003434; Mon, 11 Oct 2004 07:34: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 i9BEYoKj003433; Mon, 11 Oct 2004 07:34:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02.rdc-kc.rr.com (ms-smtp-02.rdc-kc.rr.com [24.94.166.122]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BEYma8003425 for ; Mon, 11 Oct 2004 07:34:49 -0700 (PDT) (envelope-from csgallagher@wi.rr.com) Received: from xp1 (CPE-65-25-169-159.wi.rr.com [65.25.169.159]) by ms-smtp-02.rdc-kc.rr.com (8.12.10/8.12.7) with ESMTP id i9BEYm9W016177; Mon, 11 Oct 2004 09:34:48 -0500 (CDT) Message-Id: <200410111434.i9BEYm9W016177@ms-smtp-02.rdc-kc.rr.com> Reply-To: From: "Clinton Gallagher" To: "'Atom-Syntax'" , Subject: XML Namespaces Date: Mon, 11 Oct 2004 09:34:44 -0500 Organization: METROmilwaukee MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSuGBzeE2uoBrUxRXO/5i9T0gnp1QBhA4Qg In-Reply-To: <416807E2.5090408@intertwingly.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Example: xmlns:abc="http://smallpotato.com/" xmlns:abc="http://corporategiant.com/" Please help me understand how any given derivation of XML such as RSS 1.0, RSS 2.0, Atom and so on has been created by its authors to avoid ambiguity and prevent the software process from failing to function when validation is required when two or more attempts to use the same prefix within a given document instance occurs? <%= Clinton Gallagher From owner-atom-syntax@mail.imc.org Mon Oct 11 10:58: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 KAA12252 for ; Mon, 11 Oct 2004 10:58:34 -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 i9BEpDxg005150; Mon, 11 Oct 2004 07:51: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 i9BEpDEQ005149; Mon, 11 Oct 2004 07:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from imo-m26.mx.aol.com (imo-m26.mx.aol.com [64.12.137.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BEpCQw005134 for ; Mon, 11 Oct 2004 07:51:13 -0700 (PDT) (envelope-from Svgdeveloper@aol.com) Received: from Svgdeveloper@aol.com by imo-m26.mx.aol.com (mail_out_v37_r3.7.) id f.b9.4893a0af (4320); Mon, 11 Oct 2004 10:51:00 -0400 (EDT) From: Svgdeveloper@aol.com Message-ID: Date: Mon, 11 Oct 2004 10:51:00 EDT Subject: Re: XML Namespaces To: csgallagher@metromilwaukee.com CC: atom-syntax@imc.org, rss-dev@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_b9.4893a0af.2e9bf7d4_boundary" X-Mailer: 8.0 for Windows sub 670 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part1_b9.4893a0af.2e9bf7d4_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/11/2004 3:38:11 PM GMT Daylight Time, csgallagher@wi.rr.com writes: > Example: > > xmlns:abc="http://smallpotato.com/" > xmlns:abc="http://corporategiant.com/" > > Please help me understand how any given derivation of XML such as RSS 1.0, > RSS 2.0, Atom and so on has been created by its authors to avoid ambiguity > and prevent the software process from failing to function when validation is > required when two or more attempts to use the same prefix within a given > document instance occurs? > > <%= Clinton Gallagher Hi, An XML processor which is compliant with the W3C specifications would process/compare the URLs not the namespace prefix. As far as the processor is concerned there is no ambiguity, since the namespace URIs are different. Andrew Watt --part1_b9.4893a0af.2e9bf7d4_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 10/11/2004 3:38:= 11 PM GMT Daylight Time, csgallagher@wi.rr.com writes:

Example:

xmlns:abc=3D"http://smallpotato.com/"
xmlns:abc=3D"http://corporategiant.com/"

Please help me understand how any given derivation of XML such as RSS 1.0, RSS 2.0, Atom and so on has been created by its authors to avoid ambiguity and prevent the software process from failing to function when validation is=
required when two or more attempts to use the same prefix within a given
document instance occurs?

<%=3D Clinton Gallagher


Hi,

An XML processor which is compliant with the W3C specifications would proces= s/compare the URLs not the namespace prefix.

As far as the processor is concerned there is no ambiguity, since the namesp= ace URIs are different.

Andrew Watt --part1_b9.4893a0af.2e9bf7d4_boundary-- From owner-atom-syntax@mail.imc.org Mon Oct 11 11:10:33 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 LAA13179 for ; Mon, 11 Oct 2004 11:10:32 -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 i9BF361v006485; Mon, 11 Oct 2004 08:03: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 i9BF36qu006484; Mon, 11 Oct 2004 08:03:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BF35Iq006469 for ; Mon, 11 Oct 2004 08:03:05 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9BF1gHa017588; Mon, 11 Oct 2004 16:01:48 +0100 (BST) In-Reply-To: <200410111434.i9BEYm9W016177@ms-smtp-02.rdc-kc.rr.com> References: <200410111434.i9BEYm9W016177@ms-smtp-02.rdc-kc.rr.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--1059382400; protocol="application/pkcs7-signature" Message-Id: <75B9EF87-1B96-11D9-837C-000A2797ECDA@mac.com> Cc: "'Atom-Syntax'" From: Graham Subject: Re: XML Namespaces Date: Mon, 11 Oct 2004 16:01:40 +0100 To: csgallagher@metromilwaukee.com X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--1059382400 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 11 Oct 2004, at 3:34 pm, Clinton Gallagher wrote: > xmlns:abc="http://smallpotato.com/" > xmlns:abc="http://corporategiant.com/" Add some real XML, and the problem becomes solvable. If we declare them in the same element: This is invalid XML since attribute names must be unique. If we declare them in separate elements: The innermost one applies. And obviously: Applies a different namespace to each one. Anyway, this isn't what you're asking. The simple answer is: You cannot own a namespace prefix. The abc is simply a *temporary* shorthand for "http://corporategiant.com/" or "http://smallpotato.com/". It belongs (temporarily) to whoever it's been declared to beforehand in the document. Anyway, this is wildly offtopic for the Atom list. Graham --Apple-Mail-2--1059382400 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDExMTUwMTQxWjAjBgkqhkiG9w0BCQQxFgQUWkNuS9cYe2XbyBviw76FrxY/ 7u0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAZKAjWlxVo2RWsAX2Xzh2vIhC VWknCNPkpjnM1ysXztBNqEJ4xtWq7AVYjsjy2bZU3pFqzEP5D9v6uAQSpsb6uTzd81DAQG8E4cmQ xhjLtN8ThLVDDx6Lmlk/VKuBXedCzCPErMzVbbdn+p4MX9NL7TXD+mt34b1/6KK7j/pTACF1FIqN 8l+Ekuqj735mm72+fdnaUFQ2WjF2lKX0NAZQFhDXvZNsJwTA2LelJ/m6QM9ptmB8VuA2UB2ZTbUn G2ub8wwxqbq3nlK+n4xLWRzlkoaSArmtwTIboqqWVG125CrSfD9F7tITLX5lnruAyjiFooOGStzN dv956wMI+neZngAAAAAAAA== --Apple-Mail-2--1059382400-- From owner-atom-syntax@mail.imc.org Mon Oct 11 11:27: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 LAA14545 for ; Mon, 11 Oct 2004 11:27:10 -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 i9BFJZm7008259; Mon, 11 Oct 2004 08:19:35 -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 i9BFJZDh008258; Mon, 11 Oct 2004 08:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from jay.songbird.com (jay.songbird.com [208.184.79.253]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BFJU9x008249 for ; Mon, 11 Oct 2004 08:19:30 -0700 (PDT) (envelope-from GK@ninebynine.org) Received: from Rincewind.ninebynine.org (jay.songbird.com [208.184.79.253]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id i9BFIw820677; Mon, 11 Oct 2004 08:19:00 -0700 Message-Id: <5.1.0.14.2.20041011145446.0324f658@127.0.0.1> X-Sender: gk-bulk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Oct 2004 14:58:53 +0100 To: Danny Ayers , rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com From: Graham Klyne Subject: Re: Atom and RDF Cc: rss-dev@yahoogroups.com, atom-syntax@imc.org In-Reply-To: <1f2ed5cd041010051961824df0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think one of the key benefits of RDF is described in this blog-piece by DanBri ("missing isn't broken"): http://rdfweb.org/mt/foaflog/archives/000047.html Atom's scope isn't as broad as RDF, so maybe the full-on RDF approach is more promiscuous than necessary, but I think it's important, for example, to take two or more Atom feeds, possibly containing different and/or overlapping information, and compose them in a well-defined way into a single feed. This is what RDF can do. #g -- At 14:19 10/10/04 +0200, Danny Ayers wrote: >Issues of extensibility and language interop for the Atom Syndication >Format [1] have been bouncing around the Atom (IETF) group from day >one. Right now I think discussions may (again) be at a point where >input from the RDF/FOAF community could be helpful. > >The Atom charter [2] says: >[[ >The format must be able... >...to represent additional information in an user-extensible manner. >... >The Working Group will also take steps to ensure interoperability, by - >...describing how one migrates from the various RSS versions to the >Atom syndication feed format. >]] > > >There are various dialects in use, but generally RSS syndication >material comes under the umbrella of either RSS 1.0 or RSS 2.0 (the >version numbers are only of political significance). > >RSS 1.0 [3] is defined as an RDF vocabulary, with a constrained subset >of RDF/XML as its exchange syntax (over HTTP), so there's clearly some >overlap with RDF efforts. RSS 1.0 extensions must follow the >constraints of RDF. So RDF is at least potentially a factor in Atom's >user-extensibility and must be a consideration when format migration >is under discussion. > >RSS 2.0 [4] is defined as a 'simple' XML format. It hasn't got a >namespace itself, though any material in other XML namespaces can >appeared in the document and be called an extension. Most syndication >tools (for publishing and reading) support both formats. Most >syndication tools only support enough of the RDF model to be able to >extract the syndication-domain data (there are notable exceptions, and >of course virtually all RDF tools can consume & process RSS 1.0 out of >the box). Developers of syndication tools tend to have expertise with >regular expressions. > >Aside from all else, there is (loosely) a polarization of opinion >among Atom WG members on how it should tackle extension and interop >issues, this being roughly parallel to that of RSS 1.0 vs. RSS 2.0. > >One pole is probably most easily expressed by saying Atom should've >been defined as an RDF/OWL vocabulary and the exchange syntax made >compatible with RDF/XML. > >The other pole is that Atom Core should be totally bolted down, and >extensions should simply be partitioned off using XML namespaces. >There would be no systematic approach to those extensions, anything >could go anywhere. > >I would guess that group consensus generally leans towards the latter >pole. (Come to think of it, probably everyone agrees with the >bolted-down core part). > > >In [5] Robert Sayre describes an option for applying potentially >arbitrary properties to Atom entries in a uniform fashion, which may >be enough (given a bit of polish) to disambiguate extensions into >RDF-compatible statements. His suggestion hasn't brought immediate >condemnation from the core+namespace-only camp. Which is promising. > >But how workable does this seem from the RDF point of view? To me it >looks like the kind of structural constraint suggested will go a long >way towards allowing extraction of viable RDF from fairly arbitrarily >extended Atom documents e.g. using XSLT -> RDF/XML. All the usual >suspects like FOAF and DC could be used to make richer Atom documents, >without compromising the core format. Does that sound about right? Or >wouldn't it work? Or is there a better approach to RDF-compatibility >that wouldn't worry the simple-XML camp? > >Why does it matter? I think RDF potentially stands to gain quite a lot >from Atom, in the form of a relatively lightweight but versatile and >thoroughly spec'ed transport (and editing protocol) which is likely to >gain widespread deployment. Atom can gain potentially a lot from RDF, >up front for its intuitions into modelling on the Web and longer term >through compatibility with (and adoption by) RDF-based systems. Then >everyone gains when all these systems are joined together... > >Cheers, >Danny. > >[1] http://www.intertwingly.net/wiki/pie/FrontPage >[2] http://www.ietf.org/html.charters/atompub-charter.html >[3] http://purl.org/rss/1.0/spec >[4] http://blogs.law.harvard.edu/tech/rss >[5] http://www.imc.org/atom-syntax/mail-archive/msg10481.html > >-- > >http://dannyayers.com ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From owner-atom-syntax@mail.imc.org Mon Oct 11 12:36:55 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 MAA20308 for ; Mon, 11 Oct 2004 12:36:54 -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 i9BGOHe8014414; Mon, 11 Oct 2004 09:24:17 -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 i9BGOHsb014413; Mon, 11 Oct 2004 09:24:17 -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 i9BGOGwC014406 for ; Mon, 11 Oct 2004 09:24:16 -0700 (PDT) (envelope-from dorchard@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02b.bea.com [172.16.120.56]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i9BGOIZL024100; Mon, 11 Oct 2004 09:24:18 -0700 Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Oct 2004 09:24:18 -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="US-ASCII" Subject: RE: PaceLinkRelMechanism Date: Mon, 11 Oct 2004 09:24:18 -0700 Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0AE02867@ussjex01.amer.bea.com> Thread-Topic: PaceLinkRelMechanism Thread-Index: AcStbEBHXl6w21yuQvuxkIY+DwTrNwCQi4hg From: "David Orchard" To: "Dare Obasanjo" , "Danny Ayers" , "Graham" Cc: "Atom Syntax" X-OriginalArrivalTime: 11 Oct 2004 16:24:18.0610 (UTC) FILETIME=[C1EFB920:01C4AFAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9BGOGwC014407 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In general, I agree that qnames in content are bad. But there are some advantages to authors. It can be very painful to write lots o' URIs in attributes. Any use of Qnames requires gaining freedom from significant authoring pain, which I haven't yet seen for rel values. Dave > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] On Behalf Of Dare Obasanjo > Sent: Friday, October 08, 2004 12:22 PM > To: Danny Ayers; Graham > Cc: Atom Syntax > Subject: Re: PaceLinkRelMechanism > > > > --- Danny Ayers wrote: > > > > You will then have noticed Norm's remark - "The > > announcement that the > > next version of HTML is going to use QNames in rel > > puts this question > > to bed, I think. Using anything else in Atom would > > be hard to defend." > > Having QNames in content causes a ridiculous amount of > problems in XML processing. It's unfortunate that we > are stuck with them in core XML technologies like XSLT > and W3C XML Schema but it doesn't mean this should be > allowed to spread unchecked in the XML world. > > Even the W3C TAG frowns on the practice but admits the > cat is already out of the bag > > http://www.w3.org/2001/tag/doc/qnameids.html > > ===== > THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 > I will keep a special cache of low-tech weapons and train my troops in > their use. That way -- even if the heroes manage to neutralize my power > generator and/or render the standard-issue energy weapons useless -- my > troops will not be overrun by a handful of savages armed with spears and > rocks. > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Mon Oct 11 12:48: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 MAA21060 for ; Mon, 11 Oct 2004 12:48:24 -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 i9BGfF9r015746; Mon, 11 Oct 2004 09:41: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 i9BGfFfT015745; Mon, 11 Oct 2004 09:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9BGfFmL015733 for ; Mon, 11 Oct 2004 09:41:15 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041011164102.60982.qmail@web41213.mail.yahoo.com> Received: from [24.22.182.158] by web41213.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 09:41:02 PDT Date: Mon, 11 Oct 2004 09:41:02 -0700 (PDT) From: Dare Obasanjo Subject: RE: PaceLinkRelMechanism To: David Orchard , Danny Ayers , Graham Cc: Atom Syntax In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF0AE02867@ussjex01.amer.bea.com> 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 wrote: > In general, I agree that qnames in content are bad. > But there are some > advantages to authors. It can be very painful to > write lots o' URIs in > attributes. Atom feeds are primarily going to be machine generated. Adding the significant pain in downstream processing caused by QNames in content for the 0.0001% of Atom users who will hand write their feeds does not seem to be a good cost/benefit trade off. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Mon Oct 11 13:54:43 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 NAA27499 for ; Mon, 11 Oct 2004 13:54:42 -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 i9BHhW8R021473; Mon, 11 Oct 2004 10:43: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 i9BHhWNu021472; Mon, 11 Oct 2004 10:43:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9BHhU8S021451 for ; Mon, 11 Oct 2004 10:43:31 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 11126 invoked by uid 65534); 11 Oct 2004 17:43:19 -0000 Received: from dsl-213-023-052-129.arcor-ip.net (EHLO voyager) (213.23.52.129) by mail.gmx.net (mp026) with SMTP; 11 Oct 2004 19:43:19 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Dare Obasanjo Cc: atom-syntax@imc.org Subject: Re: PaceLinkRelMechanism Date: Mon, 11 Oct 2004 19:43:07 +0200 Message-ID: <4191c5cc.978417109@smtp.bjoern.hoehrmann.de> References: <32D5845A745BFB429CBDBADA57CD41AF0AE02867@ussjex01.amer.bea.com> <20041011164102.60982.qmail@web41213.mail.yahoo.com> In-Reply-To: <20041011164102.60982.qmail@web41213.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >> In general, I agree that qnames in content are bad. >> But there are some >> advantages to authors. It can be very painful to >> write lots o' URIs in >> attributes. > >Atom feeds are primarily going to be machine >generated. Adding the significant pain in downstream >processing caused by QNames in content for the 0.0001% >of Atom users who will hand write their feeds does not >seem to be a good cost/benefit trade off. Hmm, rather than using a.Value directly you wrap a into a function call for which the function is three or four lines of code, how is that pain or significant in a meaningful way? Also, how did you derive the 0.0001% here? And why is this only relevant for "hand writing" Atom documents? From owner-atom-syntax@mail.imc.org Mon Oct 11 14:30:23 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 OAA00753 for ; Mon, 11 Oct 2004 14:30:23 -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 i9BINYPL024363; Mon, 11 Oct 2004 11:23: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 i9BINYDA024362; Mon, 11 Oct 2004 11:23:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41211.mail.yahoo.com (web41211.mail.yahoo.com [66.218.93.44]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9BINX4F024347 for ; Mon, 11 Oct 2004 11:23:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041011182332.93233.qmail@web41211.mail.yahoo.com> Received: from [24.22.182.158] by web41211.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 11:23:32 PDT Date: Mon, 11 Oct 2004 11:23:32 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkRelMechanism To: Bjoern Hoehrmann Cc: atom-syntax@imc.org In-Reply-To: <4191c5cc.978417109@smtp.bjoern.hoehrmann.de> 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: --- Bjoern Hoehrmann wrote: > > Hmm, rather than using a.Value directly you wrap a > into a function call > for which the function is three or four lines of > code, how is that pain > or significant in a meaningful way? Also, how did > you derive the 0.0001% > here? And why is this only relevant for "hand > writing" Atom documents? The problem with QNames in content is that most XML APIs do not provide easy ways to process or transmit in-scope namespace declarations. In the .NET Framework neither XmlDocument nor XmlReader do while XPathNavigator does but the API is cumbersome. Specifically a lot of APIs particularly fall apart when transmiting a fragment from an XML document with QNames in content since they don't know to serialize the in-scope namespaces at the root of the fragment. Example ex:value Grab your favorite DOM or SAX implementation in your language of choice, position yourself on the element then write the node to a stream or pass it along to another API. How well do the in-scope namespaces travel along with the node? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Mon Oct 11 15:02: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 PAA04434 for ; Mon, 11 Oct 2004 15:02: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 i9BIrlYT028676; Mon, 11 Oct 2004 11:53:47 -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 i9BIrlJa028675; Mon, 11 Oct 2004 11:53:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9BIrjVG028656 for ; Mon, 11 Oct 2004 11:53:46 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 28769 invoked by uid 65534); 11 Oct 2004 18:53:41 -0000 Received: from dsl-213-023-052-129.arcor-ip.net (EHLO voyager) (213.23.52.129) by mail.gmx.net (mp001) with SMTP; 11 Oct 2004 20:53:41 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Dare Obasanjo Cc: atom-syntax@imc.org Subject: Re: PaceLinkRelMechanism Date: Mon, 11 Oct 2004 20:53:28 +0200 Message-ID: <4194d2aa.981710825@smtp.bjoern.hoehrmann.de> References: <4191c5cc.978417109@smtp.bjoern.hoehrmann.de> <20041011182332.93233.qmail@web41211.mail.yahoo.com> In-Reply-To: <20041011182332.93233.qmail@web41211.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >The problem with QNames in content is that most XML >APIs do not provide easy ways to process or transmit >in-scope namespace declarations. In the .NET Framework >neither XmlDocument nor XmlReader do while >XPathNavigator does but the API is cumbersome. So what is XmlNode::GetNamespaceOfPrefix(...) about? I would have thought something like static String URIFromQName(XmlAttribute a) { String[] s = a.Value.Split(':'); return a.GetNamespaceOfPrefix(s[0]) + s[1]; } plus some error checking would do? From owner-atom-syntax@mail.imc.org Mon Oct 11 17:01:38 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 RAA27070 for ; Mon, 11 Oct 2004 17:01:38 -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 i9BKnIoq038509; Mon, 11 Oct 2004 13:49: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 i9BKnIlx038508; Mon, 11 Oct 2004 13:49:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9BKnHgN038496 for ; Mon, 11 Oct 2004 13:49:17 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041011204916.86241.qmail@web41210.mail.yahoo.com> Received: from [131.107.71.96] by web41210.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 13:49:16 PDT Date: Mon, 11 Oct 2004 13:49:16 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkRelMechanism To: Bjoern Hoehrmann Cc: atom-syntax@imc.org In-Reply-To: <4194d2aa.981710825@smtp.bjoern.hoehrmann.de> 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: --- Bjoern Hoehrmann wrote: > > So what is XmlNode::GetNamespaceOfPrefix(...) about? > I would have thought something like I forgot about that method. I just looked at the code with our dev lead. It's buggy so we filed some bugs about it related to a few edge cases that shouldn't affect Atom scenarios if the entire feed is loaded into the XmlDocument. This won't help me in RSS Bandit though since I use XmlReader for processing feeds not the XmlDocument. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Mon Oct 11 18:19:36 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 SAA05171 for ; Mon, 11 Oct 2004 18:19: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 i9BMAL7R044718; Mon, 11 Oct 2004 15:10: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 i9BMALV4044717; Mon, 11 Oct 2004 15:10:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9BMAJOP044708 for ; Mon, 11 Oct 2004 15:10:20 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 13458 invoked by uid 65534); 11 Oct 2004 22:10:19 -0000 Received: from dsl-213-023-052-129.arcor-ip.net (EHLO voyager) (213.23.52.129) by mail.gmx.net (mp026) with SMTP; 12 Oct 2004 00:10:19 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Dare Obasanjo Cc: atom-syntax@imc.org Subject: Re: PaceLinkRelMechanism Date: Tue, 12 Oct 2004 00:10:04 +0200 Message-ID: <419703fb.994335338@smtp.bjoern.hoehrmann.de> References: <4194d2aa.981710825@smtp.bjoern.hoehrmann.de> <20041011204916.86241.qmail@web41210.mail.yahoo.com> In-Reply-To: <20041011204916.86241.qmail@web41210.mail.yahoo.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Dare Obasanjo wrote: >> So what is XmlNode::GetNamespaceOfPrefix(...) about? >> I would have thought something like > >I forgot about that method. I just looked at the code >with our dev lead. It's buggy so we filed some bugs >about it related to a few edge cases that shouldn't >affect Atom scenarios if the entire feed is loaded >into the XmlDocument. > >This won't help me in RSS Bandit though since I use >XmlReader for processing feeds not the XmlDocument. Ok, so, how about using XmlReader.LookupNamespace(...)? From owner-atom-syntax@mail.imc.org Mon Oct 11 18:33:24 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 SAA06100 for ; Mon, 11 Oct 2004 18:33:23 -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 i9BML76t045937; Mon, 11 Oct 2004 15:21: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 i9BML79c045936; Mon, 11 Oct 2004 15:21:07 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BML6Kn045927 for ; Mon, 11 Oct 2004 15:21:07 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so162864rnk for ; Mon, 11 Oct 2004 15:21:04 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr1389456rnf; Mon, 11 Oct 2004 15:21:04 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 11 Oct 2004 15:21:03 -0700 (PDT) Message-ID: <1f2ed5cd04101115212ee4281b@mail.gmail.com> Date: Tue, 12 Oct 2004 00:21:03 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Joshua Allen Subject: Re: Atom and RDF Cc: rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, rss-dev@yahoogroups.com, atom-syntax@imc.org In-Reply-To: <0E36FD96D96FCA4AA8E8F2D199320E52032CB422@RED-MSG-43.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <0E36FD96D96FCA4AA8E8F2D199320E52032CB422@RED-MSG-43.redmond.corp.microsoft.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks guys, I'll collate the posts in a day or two and pass feedback back to the Atom list. On Mon, 11 Oct 2004 12:26:08 -0700, Joshua Allen wrote: > > HTTP), so there's clearly some overlap with RDF efforts. RSS > > 1.0 extensions must follow the constraints of RDF. So RDF is > > Are there actually any RSS 1.0 extensions in popular use? In popular terms, the FOAF stuff really seems to be gaining ground, and I've seen quite a few niche (not /quite/ the right word) things like Nature's use of the PRISM vocab. I note that > RSS 2.0 approach made it very easy for podcasting to catch hold, and > this may be a consideration when evaluating an extensibility philosophy. is a core element, so I'm not entirely sure how that relates to extensibility. Definitely something to learn from though. As is usually the case I doubt the lessons will be entirely clear cut. Check out these comments: http://gonze.com/weblog/story/5-17-4 does appear to have significant flaws, and was frozen into the spec that way. At the time I'm not even sure Userland were using it, there certainly wasn't what you'd call significant deployment. Yet now, two or so years later it's suddenly the hottest thing. Ok, maybe there is a point there in relation to extensibility - had this appeared in a 3rd-party extension, would it still have been picked up in the same way? Another question, could it have been better designed and picked up in the same way? Speaking philosophically, I'm starting to wonder if the good Mr. Winer mightn't simply have entered into a pact with some horned deity or other... > > reading) support both formats. Most syndication tools only > > support enough of the RDF model to be able to extract the > > syndication-domain data (there are notable exceptions, and of > > This is perhaps wishful. Most syndication tools do not support RDF > model at all, and simply read the RSS 1.0 file as XML. Most tools would > barf given any of a number of isomorphic RDF models which stray even > slightly from the expected XML syntax. Ok, it's syntax based, but the format and model is defined through RDF, not as a direct mapping between characters and syndication-domain information. Our dog only understands about three words* (only one of which he generally responds to**), but those words are most definitely English, not Dog. > > course virtually all RDF tools can consume & process RSS 1.0 > > out of the box). Developers of syndication tools tend to have > > Again, I would temper this -- they can consume the RDF graph, but not as > RSS (unless you meant to say "virtually all RDF-based syndication > tools"). Well no, I meant what I said - they can consume the RDF vocabulary defined in RSS. They can merge graphs, make inferences based on the statements in schema and instance data and so on. > > Why does it matter? I think RDF potentially stands to gain > > quite a lot from Atom, in the form of a relatively > > lightweight but versatile and thoroughly spec'ed transport > > (and editing protocol) which is likely to gain widespread > > How is this use case any different than using RSS (or Atom) as a > protocol for moving around audio streams, bittorrent pointers to TV > programs, and other payloads? Hmm, I was going to ask then why you distributed your RSS feed as text rather than as a zipped blob. Then I realised that it probably does get delivered as a gzipped blob. The fact that RSS can be useful with a > wide variety of payloads is evidence IMO that it defines a good > separation between the protocol and payload, and my suggestion would be > to treat RDF as an opaque payload exactly like any other. Perhaps, but I have a strong feeling that such an approach might miss out on significant potential of the Web. Opaque audio streams are one thing, they have one primary form of interpretation, but descriptive data is something else entirely. It's bad enough with documents - the web is built of HTML, not PDFs. It's clear that descriptive metadata distributed through syndication channels is useful, thats what RSS and Atom are. I suspect long term that top-level flexibility will prove more interesting than efficient tunnelling, though both probably have their place. Cheers, Danny. * "Basil", "biscuit", "sit" ** "biscuit" -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 11 21:48: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 VAA19715 for ; Mon, 11 Oct 2004 21:48:34 -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 i9C1e5Th061415; Mon, 11 Oct 2004 18:40:05 -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 i9C1e5dn061414; Mon, 11 Oct 2004 18:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9C1e58R061387 for ; Mon, 11 Oct 2004 18:40:05 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012014005.69661.qmail@web41205.mail.yahoo.com> Received: from [131.107.71.227] by web41205.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 18:40:05 PDT Date: Mon, 11 Oct 2004 18:40:05 -0700 (PDT) From: Dare Obasanjo Subject: Re: Atom and RDF To: Danny Ayers , Joshua Allen Cc: rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, rss-dev@yahoogroups.com, atom-syntax@imc.org In-Reply-To: <1f2ed5cd04101115212ee4281b@mail.gmail.com> 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: --- Danny Ayers wrote: > > does appear to have significant flaws, > and was frozen into > the spec that way. Can you name these significant flaws and point out where in the RSS 2.0 spec these flaws are enshrined. > At the time I'm not even sure > Userland were using > it, there certainly wasn't what you'd call > significant deployment. Yet > now, two or so years later it's suddenly the hottest > thing. Ok, maybe > there is a point there in relation to extensibility I knew you'd figure it out. :) > Speaking philosophically, I'm starting to wonder if > the good Mr. Winer > mightn't simply have entered into a pact with some > horned deity or > other... *sigh* Seriously, is such a comment really warranted? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Mon Oct 11 22:12: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 WAA21430 for ; Mon, 11 Oct 2004 22:12:34 -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 i9C25BTh063644; Mon, 11 Oct 2004 19:05:11 -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 i9C25BtY063643; Mon, 11 Oct 2004 19:05:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9C25BQd063625 for ; Mon, 11 Oct 2004 19:05:11 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012020512.93075.qmail@web41203.mail.yahoo.com> Received: from [131.107.71.95] by web41203.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 19:05:12 PDT Date: Mon, 11 Oct 2004 19:05:12 -0700 (PDT) From: Dare Obasanjo Subject: Re: Atom and RDF [removed crosspost] To: Dare Obasanjo , Danny Ayers , Joshua Allen Cc: atom-syntax@imc.org In-Reply-To: <20041012014005.69661.qmail@web41205.mail.yahoo.com> 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: Removing cross post. My bad, didn't realize it was CCed to a bunch of RSS/RDF lists. --- Danny Ayers wrote: > > does appear to have significant flaws, > and was frozen into > the spec that way. Can you name these significant flaws and point out where in the RSS 2.0 spec these flaws are enshrined. > At the time I'm not even sure > Userland were using > it, there certainly wasn't what you'd call > significant deployment. Yet > now, two or so years later it's suddenly the hottest > thing. Ok, maybe > there is a point there in relation to extensibility I knew you'd figure it out. :) > Speaking philosophically, I'm starting to wonder if > the good Mr. Winer > mightn't simply have entered into a pact with some > horned deity or > other... *sigh* Seriously, is such a comment really warranted? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. From owner-atom-syntax@mail.imc.org Tue Oct 12 00:04: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 AAA27670 for ; Tue, 12 Oct 2004 00:04:10 -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 i9C3txnc073469; Mon, 11 Oct 2004 20:55:59 -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 i9C3txBY073468; Mon, 11 Oct 2004 20:55:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from invasion.mail.pas.earthlink.net (invasion.mail.pas.earthlink.net [207.217.120.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C3twvI073462 for ; Mon, 11 Oct 2004 20:55:58 -0700 (PDT) (envelope-from sloan01@earthlink.net) Received: from user-uinj8dg.dialup.mindspring.com ([165.121.161.176] helo=earthlink.net) by invasion.mail.pas.earthlink.net with asmtp (Exim 4.34) id 1CHDld-0003Tm-2p for atom-syntax@imc.org; Mon, 11 Oct 2004 20:56:05 -0700 Message-ID: <410-2200410212155658580@earthlink.net> X-Priority: 3 Reply-To: sloan01@earthlink.net X-Mailer: EarthLink MailBox 2004.0.129.0 (Windows) From: "Hugh Sloan" To: atom-syntax@imc.org Subject: Venture funding contact for Atom teams Date: Tue, 12 Oct 2004 08:56:58 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-ELNK-Trace: ca7c89f1781a8af2d780f4a490ca69564776905774d2ac4bac4a065e7b26245a77d7166bf79d0108350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 165.121.161.176 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi: We are looking for early-stage technology teams working on Atom initiatives that are looking to close their first round of angel or venture funding. Please send your executive summary and funding requirements to me directly at this email address. Sincerely, Hugh J. Sloan III Managing Director & Founder Sand Hill EC http://groups.yahoo.com/group/SandHillEC/ http://www.ryze.com/go/SandHillEC Privileged information, this is intended for recipient only and not for distribution to third parties. All information is confidential. From owner-atom-syntax@mail.imc.org Tue Oct 12 04:19:44 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 EAA28232 for ; Tue, 12 Oct 2004 04:19:43 -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 i9C88ow2055670; Tue, 12 Oct 2004 01:08: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 i9C88oTZ055669; Tue, 12 Oct 2004 01:08:50 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C88nMg055630 for ; Tue, 12 Oct 2004 01:08:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so182652rnk for ; Tue, 12 Oct 2004 01:08:52 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr1554425rnh; Tue, 12 Oct 2004 01:08:52 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 12 Oct 2004 01:08:52 -0700 (PDT) Message-ID: <1f2ed5cd041012010847467346@mail.gmail.com> Date: Tue, 12 Oct 2004 10:08:52 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Atom and RDF Cc: Joshua Allen , rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, rss-dev@yahoogroups.com, atom-syntax@imc.org In-Reply-To: <20041012014005.69661.qmail@web41205.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04101115212ee4281b@mail.gmail.com> <20041012014005.69661.qmail@web41205.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 11 Oct 2004 18:40:05 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > > does appear to have significant flaws, > > and was frozen into > > the spec that way. > > Can you name these significant flaws and point out > where in the RSS 2.0 spec these flaws are enshrined. Lucas Gonze listed the following problems with the enclosure element: 1 It causes users to download big files that they will never listen to or watch, creating pointless overload on web hosts. 2 It doesn't allow us to credit the MP3 host, so we can't satisfy the netiquette of always linking back. 3 For broadband users, MP3s are not big enough to need advance caching in the first place. 4 The required content-type attribute is a bad idea in the first place. 5 The required content-length attribute should not be there. http://gonze.com/weblog/story/5-17-4 1 and 3 are bigger picture issues, so arguably could be dropped from the list. 2 could *potentially* be satisfied by a namespace-qualified extension, but as far as I'm aware no-one is doing so. Had there been a slot for this in the spec then they may have done. But ok, that could potentially be fixed. Which still leaves 4 and 5 as genuine flaws enshrined in the spec. > > Speaking philosophically, I'm starting to wonder if > > the good Mr. Winer > > mightn't simply have entered into a pact with some > > horned deity or > > other... > > *sigh* > > Seriously, is such a comment really warranted? Sorry, I find some things hard to take seriously. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 12 04:41: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 EAA29793 for ; Tue, 12 Oct 2004 04:41: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 i9C8YBDL064397; Tue, 12 Oct 2004 01:34:11 -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 i9C8YBvd064396; Tue, 12 Oct 2004 01:34:11 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C8YAhR064371 for ; Tue, 12 Oct 2004 01:34:10 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so183206rnk for ; Tue, 12 Oct 2004 01:34:16 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr1560243rnh; Tue, 12 Oct 2004 01:34:15 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 12 Oct 2004 01:34:15 -0700 (PDT) Message-ID: <1f2ed5cd041012013458bbc99f@mail.gmail.com> Date: Tue, 12 Oct 2004 10:34:15 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Joshua Allen Subject: Re: Atom and RDF Cc: Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org, Dare Obasanjo In-Reply-To: <0E36FD96D96FCA4AA8E8F2D199320E52032CBA36@RED-MSG-43.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <0E36FD96D96FCA4AA8E8F2D199320E52032CBA36@RED-MSG-43.redmond.corp.microsoft.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 11 Oct 2004 20:39:11 -0700, Joshua Allen wrote: > > happening (i.e. give a discription of what possible > > representations could be obtained for a given resource, and > > in what cases) RDF would be the natural source. > > Yeah, I actually meant to refer to the "Accepts" header, which is one of > many examples of useful metadata passed in HTTP headers. HTTP has a > metadata and extensibility story and doesn't use RDF -- and that is not > worth losing sleep over. Ok. > > Taking RDF out of RSS just doesn't compare. > > Danny was talking about Atom, and specifically about the use cases of > using Atom as a transport for routing and publishing RDF. Atom doesn't > have any RDF to "take out". And it's perfectly feasible to route and > publish RDF using Atom or RSS 2.0 without having to modify them to be > based on RDF. We already have one syndication format based on RDF, and > one based on XML. What could we possibly gain by starting a holy war > about whether the third should be switched from XML to RDF? Ok, could be wrong but I don't think Atom yet has a suitable means of doing the equivalent of . So how would you feel about RSS 2.0 items as payload in Atom? Maybe what you're suggesting (RDF as payload) is not such a bad idea, but the main reason I'd like to see Atom inherit some of the functionality RSS 1.0 has is for further decorating /descriptions/ of the payload and the properties already associated with the payload. You can already say the author of an entry is "..." but it would be useful to add, they have a Personal Profile Document at "...". Or perhaps a better example would be - the creator of the attached mp3 was "...". (I would > point out that a mapping between RDF and XML in the case of Atom is > trivial, BTW) Only if you limit Atom to the core terms. That's really the nub of the issue - building Atom that way arbitrarily restricts the kind of things it can say. Ok, as I think Graham said we might not want Atom to be as promiscuous as RDF (I hope I remembered that correctly ;-). But extensibility is in the charter. It has been suggested that additional info could go into foreign-namespaces elements. Unfortunately that suffers from the N^2 problem for interop, and doesn't in itself provide any systematic way of associated more information with the entries in the feed. Mapping to RDF would not be trivial. As has been pointed out, each entry is given a URI, which means RDF can talk about them. But then that raises the spectre of one (Atom) feed for content, one (RSS/RDF) for metadata.Or perhaps following the idea of RDF-as-payload we could have alternating content/metadata (wierd, but there might be something in it...). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 12 06:43: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 GAA07249 for ; Tue, 12 Oct 2004 06:43: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 i9CAYTCM008780; Tue, 12 Oct 2004 03:34:29 -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 i9CAYTKt008778; Tue, 12 Oct 2004 03:34:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.afp.com (smtp2.afp.com [158.50.208.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CAYTmU008733 for ; Tue, 12 Oct 2004 03:34:29 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: by smtp2.afp.com (Sendmail, from userid 1007) id C0F30468CC; Tue, 12 Oct 2004 12:34:26 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp2.afp.com (Sendmail) with ESMTP id 93270469D5for ; Tue, 12 Oct 2004 12:34:26 +0200 (CEST) Received: from sdtc05 ([158.50.180.103])by alox.afp.com (8.12.9/8.12.9) with ESMTP id i9CAYP7l013859for ; Tue, 12 Oct 2004 12:34:27 +0200 (METDST) From: "Laurent Le Meur" To: Subject: Use of the NewsML URN by other initiatives Date: Tue, 12 Oct 2004 12:34:25 +0200 Message-ID: <000601c4b047$0d1a4ad0$67b4329e@afp.local> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-MailScanner: Found to be clean Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Good news. The IPTC members have given a green light to the update of the RFC3085 (NewsML URN). Four reasons for updating it: a/ there is no provision for links to the "last revision" of a given news item in the RFC, but it is widely used. b/ there is some ambiguity in some wording (in "uniqueness considerations" section). c/ the NewsML evolution could lead us to deprecate the use of the update flags ('U' and 'A' markers). d/ We would like other initiatives (e.g. the Atom community) to be able to use the NewsML URN in their projects, and so we'd like to relax the scope of the RFC (today closely associated with NewsML NewsItems). A new RFC will be presented to the IPTC members at the next meeting, by March 2005. It could be "active" by mid-2005. Laurent Le Meur IPTC NewsML Support WP -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-atom-syntax@mail.imc.org Tue Oct 12 10:08: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 KAA21471 for ; Tue, 12 Oct 2004 10:08:49 -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 i9CDwsN8035499; Tue, 12 Oct 2004 06:58:54 -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 i9CDwse0035498; Tue, 12 Oct 2004 06:58:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CDwrTt035483 for ; Tue, 12 Oct 2004 06:58:53 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012135858.27915.qmail@web41212.mail.yahoo.com> Received: from [24.18.128.7] by web41212.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 06:58:58 PDT Date: Tue, 12 Oct 2004 06:58:58 -0700 (PDT) From: Dare Obasanjo Subject: Re: Atom and RDF To: Danny Ayers Cc: Joshua Allen , rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, rss-dev@yahoogroups.com, atom-syntax@imc.org In-Reply-To: <1f2ed5cd041012010847467346@mail.gmail.com> 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: --- Danny Ayers wrote: > > Lucas Gonze listed the following problems with the > enclosure element: > > 1 It causes users to download big files that they > will never listen to > or watch, creating pointless overload on web hosts. > 2 It doesn't allow us to credit the MP3 host, so we > can't satisfy the > netiquette of always linking back. > 3 For broadband users, MP3s are not big enough to > need advance caching > in the first place. > 4 The required content-type attribute is a bad idea > in the first place. > 5 The required content-length attribute should not > be there. > > http://gonze.com/weblog/story/5-17-4 I debunked most of these claims at http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af 1. The RSS 2.0 spec never describes this automatic downloading behavior. This was a suggested usage that Dave Winer began to evangelize outside the spec which as many have pointed out has its flaws. 2. This is true, although it did seem like a weird special case to me. 3. See (1) above 4. No it isn't. Client software should be able, to decide how to react to the enclosure [e.g. if it is audio/mpeg display a play button] without having to make additional HTTP requests to the web server even if it is just HEAD requests. 5. Agreed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 12 10:24: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 KAA23309 for ; Tue, 12 Oct 2004 10:24:08 -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 i9CEGPiG036913; Tue, 12 Oct 2004 07:16:25 -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 i9CEGPTI036912; Tue, 12 Oct 2004 07:16:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CEGOnx036903 for ; Tue, 12 Oct 2004 07:16:24 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012141629.97708.qmail@web41213.mail.yahoo.com> Received: from [24.18.128.7] by web41213.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 07:16:29 PDT Date: Tue, 12 Oct 2004 07:16:29 -0700 (PDT) From: Dare Obasanjo Subject: Re: Atom and RDF To: Danny Ayers , Joshua Allen Cc: Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org, Dare Obasanjo In-Reply-To: <1f2ed5cd041012013458bbc99f@mail.gmail.com> 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: --- Danny Ayers wrote: > > Ok, could be wrong but I don't think Atom yet has a > suitable means of > doing the equivalent of . So how would > you feel about RSS > 2.0 items as payload in Atom? An is a link to a resource with some metadata about what is at the end of the URI specified. That sounds like the element and the recently discused . > It has been suggested that additional info could go > into > foreign-namespaces elements. Unfortunately that > suffers from the N^2 > problem for interop, and doesn't in itself provide > any systematic way > of associated more information with the entries in > the feed. Mapping > to RDF would not be trivial. What is this N^2 interop problem and can you explain how it doesn't apply to using RDF? I've read Ken MacLeod's postings on the topic but as an aggregator author I felt his arguments were specious. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. From owner-atom-syntax@mail.imc.org Tue Oct 12 10:36:58 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 KAA24937 for ; Tue, 12 Oct 2004 10:36:57 -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 i9CETHW6038216; Tue, 12 Oct 2004 07:29:17 -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 i9CETHML038215; Tue, 12 Oct 2004 07:29:17 -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 i9CETGT6038204 for ; Tue, 12 Oct 2004 07:29:16 -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 1CHNeJ-0000G0-KT; Tue, 12 Oct 2004 14:29:12 +0000 Message-ID: <416BEA37.7020809@franklinmint.fm> Date: Tue, 12 Oct 2004 10:29:11 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Joshua Allen , Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org, Dare Obasanjo Subject: Re: Atom and RDF References: <0E36FD96D96FCA4AA8E8F2D199320E52032CBA36@RED-MSG-43.redmond.corp.microsoft.com> <1f2ed5cd041012013458bbc99f@mail.gmail.com> In-Reply-To: <1f2ed5cd041012013458bbc99f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > Ok, could be wrong but I don't think Atom yet has a suitable means of > doing the equivalent of . We call it content @src. MarkN and I are working on incorporating the accepted PaceContentRedux3. That's your "blob" property, remember? > > As has been pointed out, each entry is given a URI, which means RDF > can talk about them. But then that raises the spectre of one (Atom) > feed for content, one (RSS/RDF) for metadata.Or perhaps following the > idea of RDF-as-payload we could have alternating content/metadata > (wierd, but there might be something in it...). It should raise the spectre of independent resources. HTTP works better that way. I'm not "against" RDF at all, and I think it has a good extensibility story. But we don't really need RDF/XML in core. The Atom project, like some versions of RSS, has done a little activity-based planning and found that people like to make lists.[0] Adaptations of Greenspun's Tenth Rule really aren't appropriate here. Atom does not fear the other. Can we stop the crossposting now? Robert Sayre [0] (search for "activity-based planning") http://www.joelonsoftware.com/printerFriendly/uibook/chapters/fog0000000065.html From owner-atom-syntax@mail.imc.org Tue Oct 12 10:37: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 KAA24957 for ; Tue, 12 Oct 2004 10:37: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 i9CETICp038227; Tue, 12 Oct 2004 07:29: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 i9CETICe038225; Tue, 12 Oct 2004 07:29:18 -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 i9CETHrX038206 for ; Tue, 12 Oct 2004 07:29:17 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i9CEU15D007641 for ; Tue, 12 Oct 2004 10:30:02 -0400 Message-ID: <416BEA43.2090104@intertwingly.net> Date: Tue, 12 Oct 2004 10:29:23 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Separating Link Concerns References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> In-Reply-To: <4166C99A.4040603@intertwingly.net> 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 Sam Ruby wrote: > > Given that we have been around these issues before, one thing I would > like to ask is that people try to avoid making clever, provocative, and > leading questions, and instead try to provide specific and constructive > suggestions possible. I'm pleased to see that some people have taken this suggestion to heart and authored the following Paces in this area: PaceConstructAttribute PaceLinkRelPrefixReg PaceLinkRelUri PaceRelationshipConstruct Thanks! - - - It looks to me like PaceLinkRelPrefixReg and PaceRelationshipConstruct are taking that atom:link element in two different directions. I've started to pull together a PaceMetaElement in the hopes that these goals to be pursued separately and without compromise. By this point, it is clear that a number of people are concerned about the syntax of links, particularly for the common case of alternate links. (Separately, there has been opinion expressed that alternate links should not be required, particularly if an atom:content element is present, so I've authored PaceContentOrLink to cover that case). There is a concensus that PaceLinkAttrDefaults goes too far, but very little in terms of concrete suggestions as to how far is far enough. I'm hopeful that a combination of PaceLinkAttrDefaults and PaceLinkRelPrefixReg will address both the syntax concerns and the "far enough" concerns. - - - Summary: * service in a separate element * meta in a separate element * link no longer required if content is present * default values for link attributes for the common case * link rel values subject to IANA registration. Thoughts? - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Oct 12 10:44:24 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 KAA25722 for ; Tue, 12 Oct 2004 10:44:24 -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 i9CEQYA9037599; Tue, 12 Oct 2004 07:26: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 i9CEQYZX037598; Tue, 12 Oct 2004 07:26:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CEQXOQ037568 for ; Tue, 12 Oct 2004 07:26:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012142638.99788.qmail@web41213.mail.yahoo.com> Received: from [24.18.128.7] by web41213.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 07:26:38 PDT Date: Tue, 12 Oct 2004 07:26:38 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkRelMechanism To: Bjoern Hoehrmann Cc: atom-syntax@imc.org In-Reply-To: <419703fb.994335338@smtp.bjoern.hoehrmann.de> 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: --- Bjoern Hoehrmann wrote: > * Dare Obasanjo wrote: > >> So what is XmlNode::GetNamespaceOfPrefix(...) > > > >This won't help me in RSS Bandit though since I use > >XmlReader for processing feeds not the XmlDocument. > > > Ok, so, how about using > XmlReader.LookupNamespace(...)? Yeah, that works. I was thinking about places in the code where I go from XmlReader to XmlNode to handle elements I don't understand using XmlDocument.ReadNode(). However this is probably a peculiarity in RSS Bandit. So I was wrong, all the XML APIs in the .NET Framework provide mechanisms for correctly processing QNames in content. The places where they fall apart will most likely be uncommon amongst applications processing Atom feeds. Thanks for correcting me Bjoern. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 12 11:59: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 LAA03061 for ; Tue, 12 Oct 2004 11:59: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 i9CFmd3P047150; Tue, 12 Oct 2004 08:48:39 -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 i9CFmdMs047148; Tue, 12 Oct 2004 08:48:39 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFmdgT047136 for ; Tue, 12 Oct 2004 08:48:39 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so199575rnk for ; Tue, 12 Oct 2004 08:48:44 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr1660520rnf; Tue, 12 Oct 2004 08:48:44 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 12 Oct 2004 08:48:44 -0700 (PDT) Message-ID: <1f2ed5cd0410120848265c017f@mail.gmail.com> Date: Tue, 12 Oct 2004 17:48:44 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Atom and RDF Cc: Joshua Allen , Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org In-Reply-To: <20041012141629.97708.qmail@web41213.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041012013458bbc99f@mail.gmail.com> <20041012141629.97708.qmail@web41213.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 12 Oct 2004 07:16:29 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > What is this N^2 interop problem and can you explain > how it doesn't apply to using RDF? I've read Ken > MacLeod's postings on the topic but as an aggregator > author I felt his arguments were specious. I thought Ken put it rather well, but it's easy enough to describe in terms of aggregators. An aggregator with RDF support can aggregate arbitrary data (say RSS plus the author's personal information and their work schedules) as long as it's expressed as RDF/XML. It can store it. Ok, you could argue that all that could be done with XML alone. But the big difference is that because the source data has been expressed as RDF it has consistent semantics that can be used for query or inference. So I could run a query like "give me all the items friends of Joshua posted on days when he was on vacation". You could build a similar system based on XML or a RDBMS. But the N^2 problem kicks in when you try to add a new vocabulary or terms - say "starsigns". Exactly the same store and query mechanism can be used to ask "give me all the items people with the same starsign as Joshua posted on days when he was on vacation". Every term/vocab you add, has to be fitted it in with the existing infrastructure, i.e. the N systems you've already got. Whereas if your original data is expressed in RDF, you only have to fit in with 1 system. This doesn't work for XML alone as there isn't any consistent interpretation above the syntax. RDF can do it because it maps to certain bits of pretty well researched bits of predicate logic. It really justs pushes the shared language up a level is all. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 12 12:03: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 MAA03198 for ; Tue, 12 Oct 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 i9CFt6Be047909; Tue, 12 Oct 2004 08:55: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 i9CFt66b047908; Tue, 12 Oct 2004 08:55:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFt5jH047899 for ; Tue, 12 Oct 2004 08:55:05 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 28137 invoked from network); 12 Oct 2004 15:55:14 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Oct 2004 15:55:14 -0000 Message-ID: <021801c4b073$dceb43f0$200ca8c0@wkearney.com> From: "Bill Kearney" To: , "'Atom-Syntax'" , References: <200410111434.i9BEYm9W016177@ms-smtp-02.rdc-kc.rr.com> Subject: Re: XML Namespaces Date: Tue, 12 Oct 2004 11:55:13 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Example: > xmlns:abc="http://smallpotato.com/" > xmlns:abc="http://corporategiant.com/" It should fail to validate. One can't use the same prefix for a namespace within the same document. Anything attempting to 'blend' or otherwise combine different XML fragments should take care to avoid this. It's the namespace URI that's important, not the prefix. Likewise, one should generally avoid trying to use the same namespace URI with more than one prefix in a single document. This is also why many XML example documents use things like ns0, ns1, ns2 for the prefixes. You seem to have some sort of strange ideas about how the prefixes and the namespaces are supposed to work. That and your questions/comments about copyright raise a certain sense of suspicion. As a result you may find a general resistance from folks in assisting you. This may not be your intention, of course. If you've got some amazingly clever idea on how to reap riches based on copyright and/or licensing of prefixes and/or namespaces you may want to prepare yourself for disappointment. Interop does not generally lend itself to such things. -Bill Kearney Syndic8.com From owner-atom-syntax@mail.imc.org Tue Oct 12 12:27:29 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 MAA06352 for ; Tue, 12 Oct 2004 12:27:28 -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 i9CGIdnO050999; Tue, 12 Oct 2004 09:18:39 -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 i9CGIdDI050998; Tue, 12 Oct 2004 09:18:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CGIc56050986 for ; Tue, 12 Oct 2004 09:18:38 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012161844.24895.qmail@web41213.mail.yahoo.com> Received: from [24.18.128.7] by web41213.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 09:18:44 PDT Date: Tue, 12 Oct 2004 09:18:44 -0700 (PDT) From: Dare Obasanjo Subject: Re: Atom and RDF To: Danny Ayers Cc: Joshua Allen , Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org In-Reply-To: <1f2ed5cd0410120848265c017f@mail.gmail.com> 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: --- Danny Ayers wrote: > > I thought Ken put it rather well, but it's easy > enough to describe in > terms of aggregators. An aggregator with RDF support > can aggregate > arbitrary data (say RSS plus the author's personal > information and > their work schedules) as long as it's expressed as > RDF/XML. It can > store it. Ok, you could argue that all that could be > done with XML > alone. But the big difference is that because the > source data has been > expressed as RDF it has consistent semantics that > can be used for > query or inference. I'm glad you concede that it all can be done with XML alone, since I do that already today in RSS Bandit and would have called sheenanigans if you hadn't. XML nodes have a consistent structure that can be used for query as well. Semantics is all in the eye of the beholder so without concrete examples we'll be talking past each other if we I try to pick at your argument of "consistent semantics". So can you give me some examples of things that are impossible using XML-based syndication (i.e. RSS 2.0) but possible using RDF-based syndication (i.e. RSS 1.0). If you could include sample XML files as well as pseudo-code it would help to show that your arguments aren't just RDF advocacy bit are rooted in technical facts. > So I could run a query like "give me all the items > friends of Joshua > posted on days when he was on vacation". You could > build a similar > system based on XML or a RDBMS. But the N^2 problem > kicks in when you > try to add a new vocabulary or terms - say > "starsigns". Exactly the > same store and query mechanism can be used to ask > "give me all the > items people with the same starsign as Joshua posted > on days when he > was on vacation". (a) Your fundamental assumption is that the benefit of extensibility in syndication is issuing queries. As someone who has an aggregator with thousands of users and has fielded hundreds of bug reports and feature requests from users this doesn't jibe with my experience. When people want to add features to RSS or wish it could do more, I've never seen the ability to issue queries on the new data or even on the existing data in RSS being high on people's priority lists. (b) I've seen lots of claims from the RDF crowd that I can just sprinkle new stuff into RSS feeds and applications will magically understand them. Can you explain to me preferrably with pseudo code how if an aggregator is based on RDF (e.g. NewsMonster) it could be 'learn' to be a podcasting application via the famed RDF extensibility model if podcasting didn't exist before the version was shipped? (c) The so-called shared semantics RDF buys you is only in the area of issuing queries. Of all the extensions RSS Bandit supports, using RDF would not have made much of a difference if I had shipped it with only support for core RSS elements. How would being based on RDF let RSS Bandit know how to deal with extensions like admin:errorReportsTo, wfw:commentRss, annotate:reference, wfw:comment, or even xhtml:body if all it supported was the core elements in RSS 1.0? Sounds like A.I. pixie dust to me. RSF buys you a limited degree of extensibility if all you want to do is issue queries over data. Most of the valuable extensions that have shown up in RSS have little if anything to do with providing richer data that can be queried against but actually signal new tasks that aggregators need to be able to perform. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 12 12:47:22 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 MAA07817 for ; Tue, 12 Oct 2004 12:47:22 -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 i9CGcTLM052752; Tue, 12 Oct 2004 09:38:29 -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 i9CGcTRK052751; Tue, 12 Oct 2004 09:38:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CGcS1n052738 for ; Tue, 12 Oct 2004 09:38:28 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012163834.28862.qmail@web41213.mail.yahoo.com> Received: from [24.18.128.7] by web41213.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 09:38:34 PDT Date: Tue, 12 Oct 2004 09:38:34 -0700 (PDT) From: Dare Obasanjo Subject: Re: Atom and RDF To: mint@franklinmint.fm, Danny Ayers Cc: Joshua Allen , Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org, Dare Obasanjo In-Reply-To: <416BEA37.7020809@franklinmint.fm> 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: --- Robert Sayre wrote: > > I'm not "against" RDF at all, and I think it has a > good extensibility > story. But we don't really need RDF/XML in core. The > Atom project, like > some versions of RSS, has done a little > activity-based planning and > found that people like to make lists.[0] RDF is a good extensibility story for certain cases in XML syndication (1) You have existing functionality and behavior that applies to certain named items that you want to apply uniformly to new items that you may not know about. This is basically the atom:link debate. (2) You want to be able to add new data to a system and not make significant changes to be able to query against the new data. A scenario is if certain feeds start adding FOAF data to comments and posts in feeds, and yiu have a client with query capabilities it shouldn't take code changes to be able to ask questions like "Show me all comments and posts by Dare Obasanjo". These are nice but I wouldn't call them the high order bit for extensibility in syndication based on existing experience with RSS. Usually extensions require new behavior or new categories of named items instead of being capable of being shoehorned into existing concepts. Not all extensions to RSS are like this, for example the extensions to RSS in the MSDN RSS feeds (see http://msdn.microsoft.com/rss.xml for an example) would fit well into an RDF-based extensibility model. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. From owner-atom-syntax@mail.imc.org Tue Oct 12 12:53: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 MAA08551 for ; Tue, 12 Oct 2004 12:53: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 i9CGjUqJ053311; Tue, 12 Oct 2004 09:45:30 -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 i9CGjUgS053310; Tue, 12 Oct 2004 09:45:30 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CGjTbm053302 for ; Tue, 12 Oct 2004 09:45:29 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so203260rnk for ; Tue, 12 Oct 2004 09:45:37 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr1684735rnf; Tue, 12 Oct 2004 09:45:36 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 12 Oct 2004 09:45:36 -0700 (PDT) Message-ID: <1f2ed5cd04101209454b8014f7@mail.gmail.com> Date: Tue, 12 Oct 2004 18:45:36 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Atom and RDF Cc: Joshua Allen , rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, rss-dev@yahoogroups.com, atom-syntax@imc.org In-Reply-To: <20041012135858.27915.qmail@web41212.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041012010847467346@mail.gmail.com> <20041012135858.27915.qmail@web41212.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 12 Oct 2004 06:58:58 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > > Lucas Gonze listed the following problems with the > > enclosure element: > > > > 1 It causes users to download big files that they > > will never listen to > > or watch, creating pointless overload on web hosts. > > 2 It doesn't allow us to credit the MP3 host, so we > > can't satisfy the > > netiquette of always linking back. > > 3 For broadband users, MP3s are not big enough to > > need advance caching > > in the first place. > > 4 The required content-type attribute is a bad idea > > in the first place. > > 5 The required content-length attribute should not > > be there. > > > > http://gonze.com/weblog/story/5-17-4 > > I debunked most of these claims at > http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af > > 1. The RSS 2.0 spec never describes this automatic > downloading behavior. This was a suggested usage that > Dave Winer began to evangelize outside the spec which > as many have pointed out has its flaws. The spec-linked "use-case narrative" is rather suggestive. If no automatic behaviour is associated with this element then it isn't really clear why a separate element is needed rather than a HTML-style hyperlink in the content. But I guess you're right about this not really being a format issue, more of a user interface thing - would I rather have the (possibly unwanted) mp3 today, or (definitely wanted) mp3 tomorrow. > 2. This is true, although it did seem like a weird > special case to me. I don't know, with aggregate-republish systems this could get quite common. But whatever, although it's a bit untidy structurally this could be worked around by using the RSS 2.0 element on the item, sort of reverting to the pre-Userland semantics of being the description of an item rather than the item/content itself. > 3. See (1) above > > 4. No it isn't. Client software should be able, to > decide how to react to the enclosure [e.g. if it is > audio/mpeg display a play button] without having to > make additional HTTP requests to the web server even > if it is just HEAD requests. Hmm, I'm not sure about this at all. I can see how a button might be useful, but HTML links don't demand prior notification of the media type. > 5. Agreed. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 12 13:16:13 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 NAA10098 for ; Tue, 12 Oct 2004 13:16:12 -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 i9CH3TUD055249; Tue, 12 Oct 2004 10:03:29 -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 i9CH3TRA055248; Tue, 12 Oct 2004 10:03:29 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CH3Sa4055241 for ; Tue, 12 Oct 2004 10:03:28 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so204299rnk for ; Tue, 12 Oct 2004 10:03:39 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr1703943rnf; Tue, 12 Oct 2004 10:03:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 12 Oct 2004 10:03:39 -0700 (PDT) Message-ID: <1f2ed5cd041012100369977197@mail.gmail.com> Date: Tue, 12 Oct 2004 19:03:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Atom and RDF Cc: atom-syntax@imc.org In-Reply-To: <416BEA37.7020809@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <0E36FD96D96FCA4AA8E8F2D199320E52032CBA36@RED-MSG-43.redmond.corp.microsoft.com> <1f2ed5cd041012013458bbc99f@mail.gmail.com> <416BEA37.7020809@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 12 Oct 2004 10:29:11 -0400, Robert Sayre wrote: > Danny Ayers wrote: > > > > > Ok, could be wrong but I don't think Atom yet has a suitable means of > > doing the equivalent of . > > We call it content @src. MarkN and I are working on incorporating the > accepted PaceContentRedux3. That's your "blob" property, remember? Oh yes, thankyou. > > As has been pointed out, each entry is given a URI, which means RDF > > can talk about them. But then that raises the spectre of one (Atom) > > feed for content, one (RSS/RDF) for metadata.Or perhaps following the > > idea of RDF-as-payload we could have alternating content/metadata > > (wierd, but there might be something in it...). > > It should raise the spectre of independent resources. HTTP works better > that way. So why are we talking of multiple entries being delivered in a single feed? > I'm not "against" RDF at all, and I think it has a good extensibility > story. But we don't really need RDF/XML in core. I'm happy to go along with that. But I also think it would be a shame if Atom provides extensibility (which is in the charter) without allowing some form of disambiguation to assist interop. I wasn't sure if the minimal structural interpretation of properties proposed by Robert would be adequate for interop with RDF systems. But the responses in this thread that have referred to that seem to suggest it would be worthwhile. The Atom project, like > some versions of RSS, has done a little activity-based planning and > found that people like to make lists.[0] Lists are good. They are necessary for shopping. Necessary, but not sufficient. > Adaptations of Greenspun's Tenth Rule really aren't appropriate here. > > Atom does not fear the other. Can we stop the crossposting now? 300MB mp3 response attached. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 12 13:38: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 NAA12212 for ; Tue, 12 Oct 2004 13:38: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 i9CHTZ0R058021; Tue, 12 Oct 2004 10:29:35 -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 i9CHTZaQ058020; Tue, 12 Oct 2004 10:29:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHTZI2058011 for ; Tue, 12 Oct 2004 10:29:35 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 5481 invoked from network); 12 Oct 2004 17:29:44 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Oct 2004 17:29:43 -0000 Message-ID: <02e801c4b081$106809e0$200ca8c0@wkearney.com> From: "Bill Kearney" To: Cc: , , , , References: <1f2ed5cd041012010847467346@mail.gmail.com> <20041012135858.27915.qmail@web41212.mail.yahoo.com> <1f2ed5cd04101209454b8014f7@mail.gmail.com> Subject: Re: [RSS-DEV] Re: Atom and RDF Date: Tue, 12 Oct 2004 13:29:43 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Goodness but this thread has been cc'd shotgun-style out to waaay too many lists. How about choosing one and saving the rest from the thread? > > 1. The RSS 2.0 spec never describes this That'd be a good starter for most of what that spec discusses... > The spec-linked "use-case narrative" is rather suggestive. If no > automatic behaviour is associated with this element then it isn't > really clear why a separate element is needed rather than a HTML-style > hyperlink in the content. Sure there is, an enclosure with a TYPE is a lot more informative than guesswork associated with an HTML href link. > But I guess you're right about this not > really being a format issue, more of a user interface thing - would I > rather have the (possibly unwanted) mp3 today, or (definitely wanted) > mp3 tomorrow. Well, the only tool using it doesn't offer anything in the way of per-channel or other control over the attachments. You get 'em all with no selectiveness. When there's only attachments coming from one channel and you know you want it (or narcissus has already assumed you do) then it's fine. With many channels or potentially re-aggregated material (lucas' webjay for example) it's potentially a really horrible waste of bandwidth all around. > > 4. No it isn't. Client software should be able, to > > decide how to react to the enclosure [e.g. if it is > > audio/mpeg display a play button] without having to > > make additional HTTP requests to the web server even > > if it is just HEAD requests. > > Hmm, I'm not sure about this at all. I can see how a button might be > useful, but HTML links don't demand prior notification of the media > type. There's a balancing act to be considered here. One being the idea that off-peak bandwidth could be used as a way to avoid clogging up the download time. This could just as well be handled via other p2 transports (bitTorrent, ed2k, etc). However those weren't available (or popular) at the time the enclosure scheme was foisted onto the spec. The other being avoiding needless waste of bandwidth from downloading media that won't ever be consumed. This being something the client-side interface could (should) handle. Having content type, size and other info greatly aids the client in being able to make 'smarter' decisions about the content in question. This isn't something a regular HREF would usually offer. -Bill Kearney Syndic8.com From owner-atom-syntax@mail.imc.org Tue Oct 12 13:52:07 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 NAA13841 for ; Tue, 12 Oct 2004 13:52: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 i9CHiTlo059251; Tue, 12 Oct 2004 10:44:29 -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 i9CHiTkq059250; Tue, 12 Oct 2004 10:44:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHiSPr059244 for ; Tue, 12 Oct 2004 10:44:28 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 2E5FF981A7; Tue, 12 Oct 2004 13:44:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9CHidK07133; Tue, 12 Oct 2004 13:44:39 -0400 (EDT) Date: Tue, 12 Oct 2004 13:44:39 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Bill Kearney Cc: rss-dev@yahoogroups.com, rdfweb-dev@vapours.rdfweb.org, www-rdf-interest@w3.org, semanticweb@yahoogroups.com, atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF In-Reply-To: <02e801c4b081$106809e0$200ca8c0@wkearney.com> Message-ID: References: <1f2ed5cd041012010847467346@mail.gmail.com> <20041012135858.27915.qmail@web41212.mail.yahoo.com> <1f2ed5cd04101209454b8014f7@mail.gmail.com> <02e801c4b081$106809e0$200ca8c0@wkearney.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 12 Oct 2004, Bill Kearney wrote: > Goodness but this thread has been cc'd shotgun-style out to waaay too many > lists. How about choosing one and saving the rest from the thread? Note to people not sub'd to atom-syntax: I'm going to trim the CC: list and reply there only. - Lucas From owner-atom-syntax@mail.imc.org Tue Oct 12 13:56: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 NAA14379 for ; Tue, 12 Oct 2004 13:56: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 i9CHmBRp059986; Tue, 12 Oct 2004 10:48:11 -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 i9CHmBeT059985; Tue, 12 Oct 2004 10:48:11 -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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CHmA5g059976 for ; Tue, 12 Oct 2004 10:48:10 -0700 (PDT) (envelope-from lavandowska@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so617192rnl for ; Tue, 12 Oct 2004 10:48:15 -0700 (PDT) Received: by 10.38.126.23 with SMTP id y23mr2396970rnc; Tue, 12 Oct 2004 10:48:15 -0700 (PDT) Received: by 10.38.83.65 with HTTP; Tue, 12 Oct 2004 10:48:15 -0700 (PDT) Message-ID: <96d7d77c041012104865c78c2c@mail.gmail.com> Date: Tue, 12 Oct 2004 12:48:15 -0500 From: Lance Lavandowska Reply-To: Lance Lavandowska To: atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF In-Reply-To: <02e801c4b081$106809e0$200ca8c0@wkearney.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041012010847467346@mail.gmail.com> <20041012135858.27915.qmail@web41212.mail.yahoo.com> <1f2ed5cd04101209454b8014f7@mail.gmail.com> <02e801c4b081$106809e0$200ca8c0@wkearney.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > handle. Having content type, size and other info greatly aids the client in > being able to make 'smarter' decisions about the content in question. This > isn't something a regular HREF would usually offer. Wouldn't it be nice if it did? I propose these be added as optional attributes for the Link discussions. Lance On Tue, 12 Oct 2004 13:29:43 -0400, Bill Kearney wrote: > > > > 4. No it isn't. Client software should be able, to > > > decide how to react to the enclosure [e.g. if it is > > > audio/mpeg display a play button] without having to > > > make additional HTTP requests to the web server even > > > if it is just HEAD requests. > > > > Hmm, I'm not sure about this at all. I can see how a button might be > > useful, but HTML links don't demand prior notification of the media > > type. > > There's a balancing act to be considered here. One being the idea that > off-peak bandwidth could be used as a way to avoid clogging up the download > time. This could just as well be handled via other p2 transports > (bitTorrent, ed2k, etc). However those weren't available (or popular) at > the time the enclosure scheme was foisted onto the spec. The other being > avoiding needless waste of bandwidth from downloading media that won't ever > be consumed. This being something the client-side interface could (should) > handle. Having content type, size and other info greatly aids the client in > being able to make 'smarter' decisions about the content in question. This > isn't something a regular HREF would usually offer. > > -Bill Kearney > Syndic8.com > > From owner-atom-syntax@mail.imc.org Tue Oct 12 14:03: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 OAA14876 for ; Tue, 12 Oct 2004 14:03:41 -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 i9CHuth2060671; Tue, 12 Oct 2004 10:56: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 i9CHutGG060670; Tue, 12 Oct 2004 10:56:55 -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 i9CHutJQ060660 for ; Tue, 12 Oct 2004 10:56:55 -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 1CHQtS-0001iW-K0; Tue, 12 Oct 2004 17:57:02 +0000 Message-ID: <416C1AEF.3080303@franklinmint.fm> Date: Tue, 12 Oct 2004 13:57:03 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lance Lavandowska CC: atom-syntax@imc.org Subject: link (@type, @size, @etc) [was: [RSS-DEV] Re: Atom and RDF] References: <1f2ed5cd041012010847467346@mail.gmail.com> <20041012135858.27915.qmail@web41212.mail.yahoo.com> <1f2ed5cd04101209454b8014f7@mail.gmail.com> <02e801c4b081$106809e0$200ca8c0@wkearney.com> <96d7d77c041012104865c78c2c@mail.gmail.com> In-Reply-To: <96d7d77c041012104865c78c2c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Lance Lavandowska wrote: >>handle. Having content type, size and other info greatly aids the client in >>being able to make 'smarter' decisions about the content in question. This >>isn't something a regular HREF would usually offer. > > > Wouldn't it be nice if it did? I propose these be added as optional > attributes for the Link discussions. > +1 Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 12 14:48:58 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 OAA18571 for ; Tue, 12 Oct 2004 14:48:58 -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 i9CId2gW064415; Tue, 12 Oct 2004 11:39: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 i9CId2gB064414; Tue, 12 Oct 2004 11:39:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CId2wE064405 for ; Tue, 12 Oct 2004 11:39:02 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 2321 invoked from network); 12 Oct 2004 18:39:11 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Oct 2004 18:39:11 -0000 Message-ID: <034901c4b08a$c483e490$200ca8c0@wkearney.com> From: "Bill Kearney" To: "Jon Hanna" , Cc: References: <20041012173843.A0AFAFBDD04E@postie.hosting365.ie> Subject: Re: [rdfweb-dev] Re: [RSS-DEV] Re: Atom and RDF Date: Tue, 12 Oct 2004 14:38:35 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "Jon Hanna" > The element in HTML already has a type attribute (which I grant you is > optional, but arguably that's appropriate also). While there's some truth to this, there are valuable semantics in using an enclosure type of element. This offering a way for the consuming app to recognize that it's something different than the content that might be linked from the description of an item (as commonly seen in RSS). There's also an argument that could be made for just using caching as provided as per HTTP. As in, set the behavior of the client app to automagically locally cache any/all links within an item. Adding control over site local and/or depth limited of course. This is as likewise useful/wasteful as the content would "be there" but would probably get pulled a lot more often than most users would actually consume (and wreck log usage analysis techniques in the process). -Bill Kearney From owner-atom-syntax@mail.imc.org Tue Oct 12 14:50:39 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 OAA18834 for ; Tue, 12 Oct 2004 14:50:38 -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 i9CIet0R064619; Tue, 12 Oct 2004 11:40: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 i9CIetI7064618; Tue, 12 Oct 2004 11:40:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIesVJ064610 for ; Tue, 12 Oct 2004 11:40:54 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id E229E981FE for ; Tue, 12 Oct 2004 14:41:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9CIf5m19570 for ; Tue, 12 Oct 2004 14:41:05 -0400 (EDT) Date: Tue, 12 Oct 2004 14:41:05 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com Cc: atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF In-Reply-To: <02e801c4b081$106809e0$200ca8c0@wkearney.com> Message-ID: References: <1f2ed5cd041012010847467346@mail.gmail.com> <20041012135858.27915.qmail@web41212.mail.yahoo.com> <1f2ed5cd04101209454b8014f7@mail.gmail.com> <02e801c4b081$106809e0$200ca8c0@wkearney.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Well, the only tool using it doesn't offer anything in the way of > per-channel or other control over the attachments. You get 'em all with no > selectiveness. When there's only attachments coming from one channel and > you know you want it (or narcissus has already assumed you do) then it's > fine. With many channels or potentially re-aggregated material (lucas' > webjay for example) it's potentially a really horrible waste of bandwidth > all around. Yup, and that's why I turned off enclosures on Webjay, but I'm working on fixing the problems so that I can turn enclosures on again. My plan is simple: I'm going to change my feeds to Atom, then assume that the WG will do a good job with the bugs. It's a faith based approach, really. I have posted a strawman feed with enclosure support here: http://gonze.com/weblog/story/atomenclosures The relevant bits are: I have managed to convince the developer of a feed reader to implement that scheme. This worked out because he already supported Atom, he already supported RSS 2.0 enclosures, and the link[@rel="enclosure"] element is so similar to RSS 2.0 enclosures that it was trivial to code. In the short term I'd make the case for a straight swipe of enclosure semantics based on ease of implementation and likelyhood of adoption, which is pretty much 100%. In the long term I'd advocate that the group should take the same approach to enclosures as it has to any work -- adopt a set of features based on real world software, then patiently work out the bugs and try to raise the general standard of engineering. >>> 4. No it isn't. Client software should be able, to >>> decide how to react to the enclosure [e.g. if it is >>> audio/mpeg display a play button] without having to >>> make additional HTTP requests to the web server even >>> if it is just HEAD requests. I agree that would be a nice feature, but in practice the types will be wrong so often that all robust clients still have to HEAD. Webjay is a user-facing tool that reacts to media types in about the way described here, and it has to check them very carefully. I don't mean to imply that design work here should coddle bad system administration elsewhere. My point is that any metadata that's part of an href or link has to be wrapped in caveats -- the metadata is only a hint, and clients that need it to be correct have to assume that it's incorrect. - Lucas Gonze (N.B.: I prefer Atom to RSS 1.0 in this context because it's more easily convertible to/from XSPF, which is XML). From owner-atom-syntax@mail.imc.org Tue Oct 12 14:52: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 OAA18929 for ; Tue, 12 Oct 2004 14:52: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 i9CIi9KD064810; Tue, 12 Oct 2004 11:44:09 -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 i9CIi9lU064809; Tue, 12 Oct 2004 11:44:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CIi80i064795 for ; Tue, 12 Oct 2004 11:44:09 -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 (sccrmhc12) with SMTP id <20041012184412012003dgj7e>; Tue, 12 Oct 2004 18:44:13 +0000 Date: Tue, 12 Oct 2004 12:44:11 -0600 Subject: Re: Separating Link Concerns 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: <416BEA43.2090104@intertwingly.net> Message-Id: 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 Tuesday, October 12, 2004, at 08:29 AM, Sam Ruby wrote: > It looks to me like PaceLinkRelPrefixReg and PaceRelationshipConstruct > are taking that atom:link element in two different directions. I'm having a difficult time wrapping my brain around PaceRelationshipConstruct and figuring out how Atom would benefit from it. Here's what I'm getting: * if an element has @atom:href * then + we know that what it points to is somehow related to the parent element * and + if we recognize the element, we also know whatever other things that element tells us, which are different on an element-by-element basis + else we don't know anything else about it Unless there's more to it than that, then I don't see the benefit. Basically, we know that atom:href points to something. The proposed spec text is pretty cryptic to one like I who is not versed in the kind of thing (RDF, I assume) that it is based on. Do we need to say "binary"? What does that mean, exactly, that isn't communicated without the word "binary"? "The nature of the relationship is determined by the name of the element...". Okay, that's saying that there's no @rel to define the nature of the relationship. I'm not sure we need that sentence, because I think that's what would be expected, absent mention of some other method of determining the nature of the relationship. The next sentence: "If that name is in the Atom namespace, then a consumer MUST interpret it and behave according to the definition of that term in this specification." That goes without saying, I think. Next: "Otherwise the consumer MAY follow whatever definition is provided for the the term in the namespace in question." I don't suppose this is intended to imply that consumers are free to misinterpret elements from other namespaces. I don't know that we need this sentence. Next: "If the consumer has no knowledge of the term then it MAY ignore it or present the data to the end user in any manner deemed appropriate." It goes without saying that unrecognized elements from other namespaces can be ignored (unless we add some sort of "mustUnderstand" mechanism). What manner could possible seem appropriate to present an element that you only know one thing about: there's something out there that's related to the parent element? I guess I'm just not catching the vision. Would it not be more useful to be able to tie extension elements to a more tightly defined Atom construct, which would give the consumer some basis for applying default processing? Would not unknown extension elements be pretty much equally useful without knowing the one piece of information that the Relationship Construct gives us? In other words, how much more can an application do with: My data than with: My data > I've started to pull together a PaceMetaElement in the hopes that > these goals to be pursued separately and without compromise. Perhaps once I understand PaceRelationshipConstruct better, I'll understand this better too. A brief example showing the "property" and "about" attributes in action would be helpful too (I understand that it's a work in progress). If meta has a @property, does that mean that it's talking about its parent element (and that what it's saying is determined by the value of @property)? And if it has an @about, does the about point to the things that the element is talking about? Finally, am I understanding correctly that as a child of , can have @rel values that are defined in extensions (which must be QNames), but as a child of an Atom core element, it is to be limited to Atom's list of values? Or is PaceMetaElement intended to be able to coexist with PaceLinkRelPrefixReg or something like it? From owner-atom-syntax@mail.imc.org Tue Oct 12 15:11:29 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 PAA20494 for ; Tue, 12 Oct 2004 15:11:29 -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 i9CJ40GJ066173; Tue, 12 Oct 2004 12:04:00 -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 i9CJ4007066172; Tue, 12 Oct 2004 12:04:00 -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 i9CJ40PY066159 for ; Tue, 12 Oct 2004 12:04:00 -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 <2004101219040601400rfs0qe>; Tue, 12 Oct 2004 19:04:07 +0000 Date: Tue, 12 Oct 2004 13:04:05 -0600 Subject: Re: [RSS-DEV] Re: Atom and RDF 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: Message-Id: <7CADBE26-1C81-11D9-B530-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 Tuesday, October 12, 2004, at 12:41 PM, Lucas Gonze wrote: >>>> 4. No it isn't. Client software should be able, to >>>> decide how to react to the enclosure [e.g. if it is >>>> audio/mpeg display a play button] without having to >>>> make additional HTTP requests to the web server even >>>> if it is just HEAD requests. > > I agree that would be a nice feature, but in practice the types will > be wrong so often that all robust clients still have to HEAD. Webjay > is a user-facing tool that reacts to media types in about the way > described here, and it has to check them very carefully. > > I don't mean to imply that design work here should coddle bad system > administration elsewhere. My point is that any metadata that's part > of an href or link has to be wrapped in caveats -- the metadata is > only a hint, and clients that need it to be correct have to assume > that it's incorrect. > I'd prefer to have an OPTIONAL type attribute, and encourage people to omit it if they don't know how to get it right. Developers of crappy tools that put inaccurate data into their feeds should be shamed into fixing them, or pushed from the market by better tools. Making the attribute option provides a sufficient opening for developers that don't know how to get the type right. If the remote resource changes types on occasion, that can be dealt with at the time the user tries to open the enclosure. From owner-atom-syntax@mail.imc.org Tue Oct 12 15:38: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 PAA23668 for ; Tue, 12 Oct 2004 15:38: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 i9CJWBvE068588; Tue, 12 Oct 2004 12:32:11 -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 i9CJWBjg068587; Tue, 12 Oct 2004 12:32:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CJWA6e068581 for ; Tue, 12 Oct 2004 12:32:10 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 180CC982EB; Tue, 12 Oct 2004 15:32:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9CJWJ003876; Tue, 12 Oct 2004 15:32:19 -0400 (EDT) Date: Tue, 12 Oct 2004 15:32:19 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF In-Reply-To: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> Message-ID: References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 12 Oct 2004, Antone Roundy wrote: > On Tuesday, October 12, 2004, at 12:41 PM, Lucas Gonze wrote: >> >> I don't mean to imply that design work here should coddle bad system >> administration elsewhere. My point is that any metadata that's part of an >> href or link has to be wrapped in caveats -- the metadata is only a hint, >> and clients that need it to be correct have to assume that it's incorrect. >> > I'd prefer to have an OPTIONAL type attribute, and encourage people to omit > it if they don't know how to get it right. Developers of crappy tools that > put inaccurate data into their feeds should be shamed into fixing them, or > pushed from the market by better tools. Making the attribute option provides > a sufficient opening for developers that don't know how to get the type > right. If the remote resource changes types on occasion, that can be dealt > with at the time the user tries to open the enclosure. Well, I think the essential point is that these attributes are assertions, not facts, and the definition of related data structures has to acknowledge that. - Lucas From owner-atom-syntax@mail.imc.org Tue Oct 12 16:02:50 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 QAA27159 for ; Tue, 12 Oct 2004 16:02:49 -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 i9CJrnQr072125; Tue, 12 Oct 2004 12:53:49 -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 i9CJrnoS072109; Tue, 12 Oct 2004 12:53:49 -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 i9CJrllS072084 for ; Tue, 12 Oct 2004 12:53:47 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i9CJsX1G023908; Tue, 12 Oct 2004 15:54:33 -0400 Message-ID: <416C3653.4040506@intertwingly.net> Date: Tue, 12 Oct 2004 15:53:55 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lucas@gonze.com CC: Antone Roundy , atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.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 Lucas Gonze wrote: > > On Tue, 12 Oct 2004, Antone Roundy wrote: > >> On Tuesday, October 12, 2004, at 12:41 PM, Lucas Gonze wrote: >> >>> I don't mean to imply that design work here should coddle bad system >>> administration elsewhere. My point is that any metadata that's part >>> of an href or link has to be wrapped in caveats -- the metadata is >>> only a hint, and clients that need it to be correct have to assume >>> that it's incorrect. >>> >> I'd prefer to have an OPTIONAL type attribute, and encourage people to >> omit it if they don't know how to get it right. Developers of crappy >> tools that put inaccurate data into their feeds should be shamed into >> fixing them, or pushed from the market by better tools. Making the >> attribute option provides a sufficient opening for developers that >> don't know how to get the type right. If the remote resource changes >> types on occasion, that can be dealt with at the time the user tries >> to open the enclosure. > > Well, I think the essential point is that these attributes are > assertions, not facts, and the definition of related data structures has > to acknowledge that. If approved, PaceLinkAttrDefaults would make the type attribute optional. Any contemplated spec language should take in account the following: http://www.w3.org/2001/tag/doc/mime-respect.html#intro In short, the answers returned by a simple HEAD request MUST override any values of any attributes that may be found in the link element itself. In addition, I would like to point out that any size attribute would not only be non-authoritative, but is also fairly meaningless in a common scenario employed with today's enclosures: bit torrents. What you get is the size of the .torrent file, not the size of the file(s) in the torrent itself. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Oct 12 16:33: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 QAA03297 for ; Tue, 12 Oct 2004 16:33: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 i9CKNBPr074295; Tue, 12 Oct 2004 13:23:11 -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 i9CKNBN0074294; Tue, 12 Oct 2004 13:23:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CKNAHf074285 for ; Tue, 12 Oct 2004 13:23:10 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041012202247.14877.qmail@web41212.mail.yahoo.com> Received: from [131.107.71.226] by web41212.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 13:22:47 PDT Date: Tue, 12 Oct 2004 13:22:47 -0700 (PDT) From: Dare Obasanjo Subject: Re: [RSS-DEV] Re: Atom and RDF To: lucas@gonze.com Cc: atom-syntax@imc.org In-Reply-To: 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: --- Lucas Gonze wrote: > > > I agree that would be a nice feature, but in > practice the types will be > wrong so often that all robust clients still have to > HEAD. Webjay is a > user-facing tool that reacts to media types in about > the way described > here, and it has to check them very carefully. In practice, robust clients will ignore the MIME type returned by the web server and try to sniff the file to figure it out anyway. As has been shown on this list in the past, almost half the XML feeds out there use the wrong MIME types anyway. I haven't done a survey of rich media files on the Web but wouldn't be surprised to see similar discrepancies. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Oct 12 16:40:24 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 QAA04819 for ; Tue, 12 Oct 2004 16:40:23 -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 i9CKXoni074941; Tue, 12 Oct 2004 13:33: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 i9CKXogF074940; Tue, 12 Oct 2004 13:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CKXm84074932 for ; Tue, 12 Oct 2004 13:33:49 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 10925 invoked from network); 12 Oct 2004 20:33:59 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Oct 2004 20:33:58 -0000 Message-ID: <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> From: "Bill Kearney" Cc: References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> <416C3653.4040506@intertwingly.net> Subject: Re: [RSS-DEV] Re: Atom and RDF Date: Tue, 12 Oct 2004 16:33:28 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Any contemplated spec language should take in account the following: > http://www.w3.org/2001/tag/doc/mime-respect.html#intro > > In short, the answers returned by a simple HEAD request MUST override > any values of any attributes that may be found in the link element itself. So let's say something like an .mp3 file is being served up from a misconfigured server. In a HEAD request it's telling you that the file is a "text/plain" document. This is supposed to be taken as gospel and the attributes used otherwise are to be ignored? Uh, that's sort of the entire reason for using the attributes, isn't it? The answser suggested by scenario 2.2 is perhaps overly optimistic (and that's being kind) given REAL WORLD conditions. I can certainly sympathize with the point they might be trying to make about the importance of server-side configurations but, please, that ain't happenin' anytime soon. Section 4.1 of the spec is almost close to being useful: http://www.w3.org/2001/tag/doc/mime-respect.html#answer2 "Query the server, and when there is an inconsistency, choose the authoritative metadata, or Query the server, and when there is an inconsistency, prompt the user for instructions on how to proceed." The trouble being with their idea of 'authoritative'. If it's the server config then we've gotten nowhere. Or perhaps the documentation for an enclosure-like element, when used in a feed, would benefit from stating that it's use of the attributes should be considered authoritative regardless of server config. Either situation is bad, the question to ask is which is worse? Stating the resource is an .mp3 file and it being served improperly as text/plain isn't a problem when the client understands how to handle mp3 files. Conversely, should someone be trying to force something 'executable' on the user while being served up as 'text/plain' or some other 'server-allowed' datatype might introduce other woes. I'd be less concerned with these as I don't forsee too many server configurations being properly setup to block publishing of something 'harmful' such that an attribure override would 'trick' the client into mishandling it. Granted, a local client's 'handler' of such resources could be compromised such that this trick might work (ms jpeg comes to mind). But I'm inclined to think the server-side isn't going to have things figured out either. > In addition, I would like to point out that any size attribute would not > only be non-authoritative, but is also fairly meaningless in a common > scenario employed with today's enclosures: bit torrents. What you get > is the size of the .torrent file, not the size of the file(s) in the > torrent itself. Well, of course! It's not the size of the .torrent file that we care about but the actual payload it points toward. While, in some cases, it's possible to pull a pointer document like those used by BitTorrent and extract from it relevant metadata that requires additional network requests. But why bother? In the context of something like an enclosure it seems quite a bit more reasonable to indicate the metadata as attributes and save the extra trip. I sense we're crossing the wires again between what an atom entry might benefit from versus it being wrong for a feed-like situation. -Bill Kearney From owner-atom-syntax@mail.imc.org Tue Oct 12 18:11: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 SAA21367 for ; Tue, 12 Oct 2004 18:11: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 i9CM3Ijg081835; Tue, 12 Oct 2004 15:03: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 i9CM3I4b081834; Tue, 12 Oct 2004 15:03:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postal.verity.com ([192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CM3IEq081814 for ; Tue, 12 Oct 2004 15:03:18 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id BF2C29B for ; Tue, 12 Oct 2004 15:03:21 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9CM3Lhc017923 for ; Tue, 12 Oct 2004 15:03:21 -0700 (PDT) Date: Tue, 12 Oct 2004 15:07:06 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF Message-ID: In-Reply-To: <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> <416C3653.4040506@intertwingly.net> <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Tuesday, October 12, 2004 04:33:28 PM -0400 Bill Kearney wrote: > > So let's say something like an .mp3 file is being served up from a > misconfigured server. In a HEAD request it's telling you that the file is a > "text/plain" document. This is supposed to be taken as gospel and the > attributes used otherwise are to be ignored? Yes, it is gospel. MSIE can guess text/plain to HTML, then run the scripts in it. Makes it rather dangerous to look at log files. Having MIME type override the server's type opens some interesting opportunities for cross-site scripting attacks. If the web server is misconfigured, it should be changed. This is exactly the position we took on well-formed Atom feeds, right? wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Oct 12 18:46:09 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 SAA24493 for ; Tue, 12 Oct 2004 18:46: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 i9CMdWGE084072; Tue, 12 Oct 2004 15:39: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 i9CMdWV6084071; Tue, 12 Oct 2004 15:39:32 -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 i9CMdVxB084065 for ; Tue, 12 Oct 2004 15:39:31 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.3]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CHVIv-0008Gf-R2 for atom-syntax@imc.org; Tue, 12 Oct 2004 22:39:37 +0000 Message-ID: <416C5D30.6090903@franklinmint.fm> Date: Tue, 12 Oct 2004 18:39:44 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Use Case: RDF in RSS 2.0 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 Here's a fairly popular feed using RDF extensions in RSS2: http://battellemedia.com/index.xml Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 12 18:53: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 SAA24997 for ; Tue, 12 Oct 2004 18:53: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 i9CMke1F084438; Tue, 12 Oct 2004 15:46: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 i9CMkes9084437; Tue, 12 Oct 2004 15:46:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CMkdgN084429 for ; Tue, 12 Oct 2004 15:46:39 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id BEB9D4872E for ; Tue, 12 Oct 2004 18:46:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9CMkpo11408 for ; Tue, 12 Oct 2004 18:46:51 -0400 (EDT) Date: Tue, 12 Oct 2004 18:46:51 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com Cc: atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF In-Reply-To: Message-ID: References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> <416C3653.4040506@intertwingly.net> <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 12 Oct 2004, Walter Underwood wrote: > If the web server is misconfigured, it should be changed. This is > exactly the position we took on well-formed Atom feeds, right? That's a reasonable position when there's a pressing need, but the need has to be pressing because it's very hard to pull off at internet scale. Let's say the one and only usecase for an element is prefetching media for offline rendering. Let's also say that the usecase for the type attribute on that element is to determine whether the URL contained in the element is the type of media that offline rendering would be appropriate for. But since the element only every holds media intended for offline rendering, the type isn't adding information. Whether those are acceptable or wise restrictions on the element is a different conversation. My first instinct is to say that any other usecase for the element is YAGNI. - Lucas From owner-atom-syntax@mail.imc.org Tue Oct 12 20:11:27 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 UAA00521 for ; Tue, 12 Oct 2004 20:11:26 -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 i9D031Zf089240; Tue, 12 Oct 2004 17:03:01 -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 i9D031K0089237; Tue, 12 Oct 2004 17:03:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D02xZ7089139 for ; Tue, 12 Oct 2004 17:03:00 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 13 Oct 2004 10:02:51 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 13 Oct 2004 10:02:39 +1000 Subject: Re: [RSS-DEV] Re: Atom and RDF From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13/10/04 8:46 AM, "Lucas Gonze" wrote: > But since the element only every holds media intended for offline > rendering, the type isn't adding information. what if @type in a feed item was "application/svg+xml" ... would you want webjay attempting to prefetch that? (assuming it knows squat about handling svg+xml, being an mp3 player at heart) e. From owner-atom-syntax@mail.imc.org Tue Oct 12 20:17:13 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 UAA01042 for ; Tue, 12 Oct 2004 20:17:12 -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 i9D09O1q089859; Tue, 12 Oct 2004 17:09: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 i9D09OV4089858; Tue, 12 Oct 2004 17:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D09NbN089850 for ; Tue, 12 Oct 2004 17:09:24 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 13 Oct 2004 10:09:46 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 13 Oct 2004 10:09:34 +1000 Subject: Re: [RSS-DEV] Re: Atom and RDF From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13/10/04 6:33 AM, "Bill Kearney" wrote: > Uh, that's sort of the entire reason for using the attributes, isn't it? not necessarily. if a feed contained these elements: then something like webjay wouldn't need to HEAD the first element at all. It can ignore it totally. Similarly an aggregator user-agent could do something intelligent with this... ... choosing the format the user prefers, and avoiding the formats she hates (midi! karaoke!!). Only when attempting to download the "application/mpeg" enclosure might the aggregator be faced with handling an inconsistency. It doesn't care if the "audio/midi" file is served as "text/plain" because it will never look at it. e. From owner-atom-syntax@mail.imc.org Tue Oct 12 21:23:19 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 VAA05782 for ; Tue, 12 Oct 2004 21:23:19 -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 i9D1Eict094769; Tue, 12 Oct 2004 18:14: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 i9D1EiHq094768; Tue, 12 Oct 2004 18:14:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D1Egae094762 for ; Tue, 12 Oct 2004 18:14:43 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id CAAA1981AB; Tue, 12 Oct 2004 21:14:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9D1EtK08901; Tue, 12 Oct 2004 21:14:55 -0400 (EDT) Date: Tue, 12 Oct 2004 21:14:55 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Eric Scheid Cc: Atom Syntax Subject: Re: [RSS-DEV] Re: Atom and RDF In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Oct 2004, Eric Scheid wrote: > On 13/10/04 8:46 AM, "Lucas Gonze" wrote: > >> But since the element only every holds media intended for offline >> rendering, the type isn't adding information. > > what if @type in a feed item was "application/svg+xml" ... would you want > webjay attempting to prefetch that? (assuming it knows squat about handling > svg+xml, being an mp3 player at heart) I wouldn't want that. It is better to avoid having to test resources that I know are going to come up negative. But webjay is a web app. A prefetch handler running unattended on a client machine is in a different position, since it has plenty of bandwidth and time. ... Here's a different line of argument. One of the main usecases for RSS 2.0 enclosures is BitTorrent files. The mime type of a BitTorrent file describes the seed document, not the bytes you get via the seed. Therefore it is already impossible to filter by type. And if we did find a compelling enough story to want to know the type of the URL referenced in the enclosure, we would want both the type of the seed file and the result file, and that opens up yet another can of worms. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 05:52: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 FAA07499 for ; Wed, 13 Oct 2004 05:52:05 -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 i9D9hoCk023979; Wed, 13 Oct 2004 02:43: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 i9D9hoDe023978; Wed, 13 Oct 2004 02:43:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9hno1023928 for ; Wed, 13 Oct 2004 02:43:49 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CHffl-0002I7-00; Wed, 13 Oct 2004 10:43:53 +0100 Date: Wed, 13 Oct 2004 10:43:53 +0100 From: James Aylett To: Atom Syntax Subject: Re: [RSS-DEV] Re: Atom and RDF Message-ID: <20041013094353.GB5713@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 12, 2004 at 09:14:55PM -0400, Lucas Gonze wrote: > One of the main usecases for RSS 2.0 enclosures is BitTorrent files. The > mime type of a BitTorrent file describes the seed document, not the bytes > you get via the seed. Therefore it is already impossible to filter by > type. And if we did find a compelling enough story to want to know the > type of the URL referenced in the enclosure, we would want both the type > of the seed file and the result file, and that opens up yet another can of > worms. But if the feed author uses an optional type attribute to indicate that the enclosure/link is a BitTorrent seed file, then the client can do something different to what it might find if type is given as SVG (or absent). BitTorrent files aren't that big, are they? So it could grab it automatically, and if it turns out not to be the correct MIME type from the server, close the connection before it gets too much rubbish thrown at it. (Admittedly this relies on having more control over the underlying connection than you get with most HTTP libraries; the conservative approach in that case would be to HEAD it first.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Wed Oct 13 05:58: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 FAA07886 for ; Wed, 13 Oct 2004 05:58:34 -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 i9D9qfB9026807; Wed, 13 Oct 2004 02:52: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 i9D9qfij026806; Wed, 13 Oct 2004 02:52:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9D9qe0N026795 for ; Wed, 13 Oct 2004 02:52:40 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CHfoW-0002fB-00; Wed, 13 Oct 2004 10:52:56 +0100 Date: Wed, 13 Oct 2004 10:52:56 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: [RSS-DEV] Re: Atom and RDF Message-ID: <20041013095256.GC5713@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <20041012202247.14877.qmail@web41212.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041012202247.14877.qmail@web41212.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 12, 2004 at 01:22:47PM -0700, Dare Obasanjo wrote: > In practice, robust clients will ignore the MIME type > returned by the web server and try to sniff the file > to figure it out anyway. As has been shown on this > list in the past, almost half the XML feeds out there > use the wrong MIME types anyway. I haven't done a > survey of rich media files on the Web but wouldn't be > surprised to see similar discrepancies. While I appreciate the interop reasons for doing this, doesn't Firefox require that the MIME type is appropriate for doing things like loading stylesheets, XML pages, handing off to third party apps for video and so forth? So there is a real case of something doing what the specs say should be done, and I haven't heard as much criticism of that as the idea has been given on this list. I'm inclined to take the Google-view [1]: the web is big, and bits of it will be inconvenient or impossible to get to, but that doesn't matter because the web is SO big that there'll be something else out there that you can get to. After all, this already happens to some extent - RSS Bandit may work round incorrect MIME types, but it refuses to parse feeds which use undeclared namespace prefixes. When a feed exists but doesn't work, I just ignore it and find something else to do. Life is too short. Most people /don't/ file bug reports, they just move on. [1] Okay, maybe Google doesn't think like this explicitly :-) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Wed Oct 13 06:20: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 GAA09267 for ; Wed, 13 Oct 2004 06:19:59 -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 i9DADI4w036096; Wed, 13 Oct 2004 03:13: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 i9DADIwl036094; Wed, 13 Oct 2004 03:13:18 -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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DADIu9036065 for ; Wed, 13 Oct 2004 03:13:18 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so247201rnk for ; Wed, 13 Oct 2004 03:13:32 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr2001983rnf; Wed, 13 Oct 2004 03:13:32 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 03:13:32 -0700 (PDT) Message-ID: <1f2ed5cd04101303131b78fd81@mail.gmail.com> Date: Wed, 13 Oct 2004 12:13:32 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Atom and RDF Cc: Joshua Allen , Jon Hanna , www-rdf-interest@w3.org, atom-syntax@imc.org In-Reply-To: <20041012161844.24895.qmail@web41213.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd0410120848265c017f@mail.gmail.com> <20041012161844.24895.qmail@web41213.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 12 Oct 2004 09:18:44 -0700 (PDT), Dare Obasanjo wrote: > XML nodes have a consistent structure that can be used > for query as well. Semantics is all in the eye of the > beholder so without concrete examples we'll be talking > past each other if we I try to pick at your argument > of "consistent semantics". I'm referring to semantics in the IT sense, broadly "The meaning associated with a set of symbols in a given language, which is determined by the syntactic structure of the symbols, as well as knowledge captured in an interpretative model." [1] More specifically, the formal logical semantics defined in the RDF and OWL specifications [2], [3]. There are concrete examples in the specs. > Sounds like A.I. pixie dust to me. Well, ok, and I don't expect your opinion to be changed by mere evidence and logical proof. I'm afraid I haven't time right now to find suitable links, coincidentally I've got some interesting aggregator development work to do. > RSF buys you a limited degree of extensibility if all > you want to do is issue queries over data. Most of the > valuable extensions that have shown up in RSS have > little if anything to do with providing richer data > that can be queried against but actually signal new > tasks that aggregators need to be able to perform. Hardly any of the extensions for general syndication (listed previously by Ian) or those used in science publishing (listed previously by Tony) signal new tasks. But even where new tasks are involved, models like that of RDF can help to describe them methodically and to interpret them consistently. I don't deny there's a lot of interesting and useful stuff that can be done with XML and desktop-style programming models. But it seems to me that things get considerably more interesting and useful when you add a Web-friendly data model like RDF's. Cheers, Danny. [1] http://www.uhnres.utoronto.ca/ehealth/html/glossary/eh_glossary.shtml [2] http://www.w3.org/TR/rdf-mt/ [3] http://www.w3.org/TR/owl-semantics/ -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 06:57:44 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 GAA11811 for ; Wed, 13 Oct 2004 06:57:43 -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 i9DAnT37050645; Wed, 13 Oct 2004 03:49:29 -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 i9DAnTs2050644; Wed, 13 Oct 2004 03:49:29 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DAnSsh050627 for ; Wed, 13 Oct 2004 03:49:29 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so247959rnk for ; Wed, 13 Oct 2004 03:49:45 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr1985026rnf; Wed, 13 Oct 2004 03:49:45 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 03:49:45 -0700 (PDT) Message-ID: <1f2ed5cd0410130349e5238db@mail.gmail.com> Date: Wed, 13 Oct 2004 12:49:45 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Walter Underwood Subject: Re: [RSS-DEV] Re: Atom and RDF Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> <416C3653.4040506@intertwingly.net> <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 12 Oct 2004 15:07:06 -0700, Walter Underwood wrote: > If the web server is misconfigured, it should be changed. This is > exactly the position we took on well-formed Atom feeds, right? In the case of media files, agreed. I don't think there's anything like the same mess about providing the right header with multimedia and other blob types compared to the markup continuum: plain text/html/xhtml/xml/lisp... Quick glance at an Apache mime.types would seem consistent with this (though I see no entry for BitTorrent). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 06:59: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 GAA11965 for ; Wed, 13 Oct 2004 06:59:13 -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 i9DAreb4052388; Wed, 13 Oct 2004 03:53: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 i9DArevY052387; Wed, 13 Oct 2004 03:53:40 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DArdHL052352 for ; Wed, 13 Oct 2004 03:53:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so248076rnk for ; Wed, 13 Oct 2004 03:53:53 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr2029815rnh; Wed, 13 Oct 2004 03:53:53 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 03:53:53 -0700 (PDT) Message-ID: <1f2ed5cd041013035320c8b227@mail.gmail.com> Date: Wed, 13 Oct 2004 12:53:53 +0200 From: Danny Ayers Reply-To: Danny Ayers To: lucas@gonze.com Subject: Re: [RSS-DEV] Re: Atom and RDF Cc: Eric Scheid , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 12 Oct 2004 21:14:55 -0400 (EDT), Lucas Gonze wrote: > Here's a different line of argument. > > One of the main usecases for RSS 2.0 enclosures is BitTorrent files. The > mime type of a BitTorrent file describes the seed document, not the bytes > you get via the seed. Therefore it is already impossible to filter by > type. And if we did find a compelling enough story to want to know the > type of the URL referenced in the enclosure, we would want both the type > of the seed file and the result file, and that opens up yet another can of > worms. Sorry if you've already mentioned this before (this thread is a bit unwieldy), but how do you suggest dealing with this difference (type->media, type->descriptor->media)? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 10:39: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 KAA03658 for ; Wed, 13 Oct 2004 10:39:54 -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 i9DEVRCO085341; Wed, 13 Oct 2004 07:31:27 -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 i9DEVRC2085340; Wed, 13 Oct 2004 07:31:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEVPgH085325 for ; Wed, 13 Oct 2004 07:31:26 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 14D02981A1; Wed, 13 Oct 2004 10:31:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DEVfs01044; Wed, 13 Oct 2004 10:31:41 -0400 (EDT) Date: Wed, 13 Oct 2004 10:31:40 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Danny Ayers Cc: lucas@gonze.com, Eric Scheid , Atom Syntax Subject: enclosures: type and length In-Reply-To: <1f2ed5cd041013035320c8b227@mail.gmail.com> Message-ID: References: <1f2ed5cd041013035320c8b227@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Oct 2004, Danny Ayers wrote: > > On Tue, 12 Oct 2004 21:14:55 -0400 (EDT), Lucas Gonze wrote: > >> Here's a different line of argument. >> >> One of the main usecases for RSS 2.0 enclosures is BitTorrent files. The >> mime type of a BitTorrent file describes the seed document, not the bytes >> you get via the seed. Therefore it is already impossible to filter by >> type. And if we did find a compelling enough story to want to know the >> type of the URL referenced in the enclosure, we would want both the type >> of the seed file and the result file, and that opens up yet another can of >> worms. > > Sorry if you've already mentioned this before (this thread is a bit > unwieldy), but how do you suggest dealing with this difference > (type->media, type->descriptor->media)? By avoiding it if at all possible. I brought up the example to show that the type attribute is not doing any work in existing enclosure software, because if it was then BitTorrent types would be breaking things. This is in support of my general point that the type attribute is YAGNI. There are no application requirements which depend on it. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 10:42: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 KAA03928 for ; Wed, 13 Oct 2004 10:42: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 i9DEasjk086080; Wed, 13 Oct 2004 07:36:54 -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 i9DEas5P086079; Wed, 13 Oct 2004 07:36:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEarbE086071 for ; Wed, 13 Oct 2004 07:36:53 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 88190487A4; Wed, 13 Oct 2004 10:37:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DEbAS05121; Wed, 13 Oct 2004 10:37:10 -0400 (EDT) Date: Wed, 13 Oct 2004 10:37:10 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Danny Ayers Cc: Walter Underwood , atom-syntax@imc.org Subject: enclosures: types In-Reply-To: <1f2ed5cd0410130349e5238db@mail.gmail.com> Message-ID: References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> <416C3653.4040506@intertwingly.net> <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> <1f2ed5cd0410130349e5238db@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Oct 2004, Danny Ayers wrote: > On Tue, 12 Oct 2004 15:07:06 -0700, Walter Underwood wrote: > >> If the web server is misconfigured, it should be changed. This is >> exactly the position we took on well-formed Atom feeds, right? > > In the case of media files, agreed. I don't think there's anything > like the same mess about providing the right header with multimedia > and other blob types compared to the markup continuum: plain > text/html/xhtml/xml/lisp... > > Quick glance at an Apache mime.types would seem consistent with this > (though I see no entry for BitTorrent). The situation is much worse for media files, because: 1) proliferation of media formats means that there are more mime types for front line coders to learn. 2) the major vendors (Apple, MS, Real) are in a standards war and see open standards like MIME as being in their competitors' interests. 3) a large portion of media files are served by proprietary servers that ship misconfigured. I'd guess that 75% of Windows Media files are served as text/plain. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 10:48:26 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 KAA04536 for ; Wed, 13 Oct 2004 10:48:26 -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 i9DEfpKA086858; Wed, 13 Oct 2004 07:41:51 -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 i9DEfpjp086857; Wed, 13 Oct 2004 07:41:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEfn7n086849 for ; Wed, 13 Oct 2004 07:41:50 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id AAA88981EB; Wed, 13 Oct 2004 10:42:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DEg6N08853; Wed, 13 Oct 2004 10:42:06 -0400 (EDT) Date: Wed, 13 Oct 2004 10:42:06 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: James Aylett Cc: Atom Syntax Subject: enclosures: types In-Reply-To: <20041013094353.GB5713@tartarus.org> Message-ID: References: <20041013094353.GB5713@tartarus.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Oct 2004, James Aylett wrote: > But if the feed author uses an optional type attribute to indicate > that the enclosure/link is a BitTorrent seed file, then the client can > do something different to what it might find if type is given as SVG > (or absent). > > BitTorrent files aren't that big, are they? No, but HEAD is even smaller. What's missing in this conversation is an application requirement. What would the client do differently for SVG than BitTorrent, and why does it belong at this layer? That's why YAGNI has been my mantra. The type attribute introduces bugs but not features. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 11:07: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 LAA05942 for ; Wed, 13 Oct 2004 11:07: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 i9DEx3Uw088948; Wed, 13 Oct 2004 07:59:03 -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 i9DEx360088947; Wed, 13 Oct 2004 07:59:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DEx26W088939 for ; Wed, 13 Oct 2004 07:59:02 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 108054873C for ; Wed, 13 Oct 2004 10:59:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DExJk21252 for ; Wed, 13 Oct 2004 10:59:19 -0400 (EDT) Date: Wed, 13 Oct 2004 10:59:19 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: atom-syntax@imc.org Subject: enclosures: type and length In-Reply-To: <200410130725.i9D7Pss05185@sirius.sns.net.ua> Message-ID: References: <200410130725.i9D7Pss05185@sirius.sns.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Oct 2004, Alex Kolesnichenko wrote: > r> 4 The required content-type attribute is a bad idea in the first place. > r> 5 The required content-length attribute should not be there. ... > And > 4 and 5 can help both user and software to choose the conditions when the > file should be downloaded or simply shown as a link. I'd better made length > attribute optional in order to make publishing of streaming content > possible. The situation when client software has to roundtrip to server > making HEAD queries for discovering trivial attributes is inacceptable. Even > if content-type and length will be broken, the problem can be resolved in > downloading process. Why is it unacceptable? What application requirements does that roundtrip affect? I realize that inefficiency is bad in itself, however demonstrating that there is ineffiency is not so simple as wishing a more efficient technology existed. The meaning of an enclosure is that this is an item to pre-cache, and the meaning of the type is that this is an item to pre-cache. The type is redundant, so it does no work, and the type will be a large source of bugs, so it has a high cost. > s are broken from the another side -- I cannot specify more than > one . And, the worst, I cannot specify alternative s > (ie. user could have a choice to download radio show in either MP3 record > format or its script in DOC). :) This is a playlist usecase! See http://gonze.com/xspf/xspf-draft-8.html#Usecases%20for%20playlists The idea of syndicating playlists is right where I'm headed, and it's the reason I'm taking the trouble to deal with enclosures. See http://webjay.org/by/lucas_gonze/organism.xspf for a playlist which supports alternate IDs *and* the Atom modified/issued/id elements. Those playlists could easily be converted to Atom, but they could also be considered feeds without any conversion. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 11:13:07 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 LAA06916 for ; Wed, 13 Oct 2004 11:13: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 i9DF1xUL089278; Wed, 13 Oct 2004 08:01:59 -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 i9DF1xcM089277; Wed, 13 Oct 2004 08:01:59 -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 i9DF1wuX089268 for ; Wed, 13 Oct 2004 08:01:58 -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 1CHkdd-0001rb-0e; Wed, 13 Oct 2004 15:02:01 +0000 Message-ID: <416D4366.2000405@franklinmint.fm> Date: Wed, 13 Oct 2004 11:01:58 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lucas@gonze.com CC: James Aylett , Atom Syntax Subject: Re: enclosures: types References: <20041013094353.GB5713@tartarus.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Lucas Gonze wrote: > > No, but HEAD is even smaller. > > What's missing in this conversation is an application requirement. What > would the client do differently for SVG than BitTorrent, and why does it > belong at this layer? That's why YAGNI has been my mantra. The type > attribute introduces bugs but not features. > I would agree with you if HTTP was perfect, but HEAD requests do have a cost, and not all resources respond to HEAD requests accurately. Let's say I'm subscribed to 1000 feeds in Project D.U.[0] or something similar, and I have it configured to show me .mp3 enclosures in a special pane (I don't want .wma .ra files). Is the aggregator supposed HEAD every single enclosure link to find out which ones are mp3s? I think the type attribute is useful metadata in the same sense that the title attribute is. If we omit it, we'll just see stuff like this: That's something we often see in HTML. There's your use case. Robert Sayre [0] http://projectdu.com/ From owner-atom-syntax@mail.imc.org Wed Oct 13 11:16:29 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 LAA07132 for ; Wed, 13 Oct 2004 11:16:28 -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 i9DF47Nh089694; Wed, 13 Oct 2004 08:04:07 -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 i9DF47co089693; Wed, 13 Oct 2004 08:04:07 -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 i9DF471k089685 for ; Wed, 13 Oct 2004 08:04:07 -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 <2004101315042001400s7ak9e>; Wed, 13 Oct 2004 15:04:20 +0000 Date: Wed, 13 Oct 2004 09:04:19 -0600 Subject: Re: enclosures: types 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: Message-Id: <284F3CCA-1D29-11D9-A16E-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, October 13, 2004, at 08:42 AM, Lucas Gonze wrote: > That's why YAGNI has been my mantra. The type attribute introduces > bugs but not features. Crappy feeds introduce bugs. A few people on this list have chanted in opposition to your mantra, and my opinion harmonizes with theirs. My application, CaRP, which only uses image/gif and image/jpeg enclosures, uses the type attribute to decide whether to try displaying an enclosure. I have yet to have a customer complain. I suspect they'd be more likely to complain if I did an almost-always-unnecessary HEAD on every enclosure to see whether the (possibly misconfigured) server agreed with the feed, since that would slow performance. For me and mine, @type is a useful feature. If it is less useful for some other application, let that application HEAD the enclosures. From owner-atom-syntax@mail.imc.org Wed Oct 13 11:20: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 LAA07564 for ; Wed, 13 Oct 2004 11:20: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 i9DF9p8M090499; Wed, 13 Oct 2004 08:09:51 -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 i9DF9pgU090498; Wed, 13 Oct 2004 08:09:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DF9nJh090487 for ; Wed, 13 Oct 2004 08:09:50 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 95B189825F; Wed, 13 Oct 2004 11:10:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DF9uH28997; Wed, 13 Oct 2004 11:09:56 -0400 (EDT) Date: Wed, 13 Oct 2004 11:09:56 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Eric Scheid Cc: Atom Syntax Subject: enclsoures: multipile enclosures in an entry In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Oct 2004, Eric Scheid wrote: > if a feed contained these elements: > > > > > then something like webjay wouldn't need to HEAD the first element at all. > It can ignore it totally. Similarly an aggregator user-agent could do > something intelligent with this... > > > > > > > ... choosing the format the user prefers, and avoiding the formats she hates > (midi! karaoke!!). I'm separating out this comment of yours because Alex brought up the same issue. I'd say again: there's no usecase for this; if there were it could be satisfied within existing web architecture by sending preferred types in the Accept header; if there is really a pressing reason to do this then Atom is slipping into playlist functionality and should start by looking for a playlist format that already solves the problem. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 11:32:04 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 LAA08425 for ; Wed, 13 Oct 2004 11:32: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 i9DFLf9A092757; Wed, 13 Oct 2004 08:21: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 i9DFLeVv092756; Wed, 13 Oct 2004 08:21:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFLd6v092750 for ; Wed, 13 Oct 2004 08:21:40 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CHkww-0000ti-00; Wed, 13 Oct 2004 16:21:58 +0100 Date: Wed, 13 Oct 2004 16:21:58 +0100 From: James Aylett To: Atom Syntax Subject: Re: enclosures: types Message-ID: <20041013152158.GO5713@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <20041013094353.GB5713@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 13, 2004 at 10:42:06AM -0400, Lucas Gonze wrote: > >BitTorrent files aren't that big, are they? > No, but HEAD is even smaller. Erm ... so? If you have reason to believe you'll get a BT file, and the user wants things downloaded automatically, what reason do you have not to grab it? A similar mechanism regulates downloading of CSS stylesheets in browsers ... > What's missing in this conversation is an application requirement. What > would the client do differently for SVG than BitTorrent, and why does it > belong at this layer? That's why YAGNI has been my mantra. The type > attribute introduces bugs but not features. If a client doesn't know what to do with SVG, why would it automatically download it? Even making the HEAD requests has costs (ignoring the possibility that the HEAD might lie [1]), and if I /know/ that the type marked is something I can do nothing with, why should I pay a cost on the off-chance that it's marked wrongly? The only reason BT files would be treated differently to SVG is if the client knows how to deal with one and not the other. That on downloading, BT files should cause another fetch is a wrinkle, but not a unique one - there are formats where auxiliary resources might want to be automatically downloaded to enable immediate display, after all. With type optional, anything that can't guarantee to get it right can just not produce the type attribute, and then you do have to HEAD or GET to figure out what it is, but that's at least making life easier. I wouldn't want my connected MP3 player downloading anything not explicitly marked as MP3s, but for them it can go and get as many as possible automatically and I'll be happy - which is, in my understanding, one of the main uses of enclosures in RSS 2.0 in the first place. [1] RFC 2616 is cagey about this; HEAD responses SHOULD contain the same metadata as the equivalent GET responses. However clients can rely on that metadata for updating cached entities and figuring out staleness of cached entities (which, interestingly, may not include Content-Type - which suggests that the resource is considered the same even if the MIME type changes; the RFC is silent on this AFAICT, and I can't think through all the implications of this). This strikes me as strange, at the very least. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Wed Oct 13 11:33:57 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 LAA08625 for ; Wed, 13 Oct 2004 11:33:57 -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 i9DFLgX5092765; Wed, 13 Oct 2004 08:21: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 i9DFLgNB092764; Wed, 13 Oct 2004 08:21:42 -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 i9DFLf5B092746 for ; Wed, 13 Oct 2004 08:21:41 -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 <2004101315215401300c7q22e>; Wed, 13 Oct 2004 15:21:54 +0000 Date: Wed, 13 Oct 2004 09:21:53 -0600 Subject: Re: enclosures: type and length 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: Message-Id: <9CDBFAC2-1D2B-11D9-A16E-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, October 13, 2004, at 08:59 AM, Lucas Gonze wrote: > The meaning of an enclosure is that this is an item to pre-cache, and > the meaning of the type is that this is an item to pre-cache. The > type is redundant, so it does no work, and the type will be a large > source of bugs, so it has a high cost. "image/jpeg" means "pre-cache this"? Silly me, I'd been interpreting it to mean that the enclosure was a JPEG image. > :) This is a playlist usecase! See > http://gonze.com/xspf/xspf-draft-8.html#Usecases%20for%20playlists > > The idea of syndicating playlists is right where I'm headed, and it's > the reason I'm taking the trouble to deal with enclosures. So again I say, if you're playlist-handling application finds content-type to be too unreliable, go ahead and ignore it. But there's no reason to assume that other applications find it equally problematic. From owner-atom-syntax@mail.imc.org Wed Oct 13 11:42: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 LAA09154 for ; Wed, 13 Oct 2004 11:42: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 i9DFWE9d094199; Wed, 13 Oct 2004 08:32:14 -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 i9DFWEgG094198; Wed, 13 Oct 2004 08:32:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFWDLF094127 for ; Wed, 13 Oct 2004 08:32:13 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 14 Oct 2004 01:32:10 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Oct 2004 01:31:58 +1000 Subject: Re: enclosures: type and length From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/10/04 12:31 AM, "Lucas Gonze" wrote: >> Sorry if you've already mentioned this before (this thread is a bit >> unwieldy), but how do you suggest dealing with this difference >> (type->media, type->descriptor->media)? > > By avoiding it if at all possible. I brought up the example to show that > the type attribute is not doing any work in existing enclosure software, > because if it was then BitTorrent types would be breaking things. > > This is in support of my general point that the type attribute is YAGNI. > There are no application requirements which depend on it. What about content negotiation? if an aggregator sees an enclosure link to an "application/mpeg" resource, could it not use content negotiation to ask for the resource with a high preference for a BitTorrent stub? If the server has a BT stub, it can send that instead of the actual mpeg, declaring that it is a BT stub in the response headers. Of course if the aggregator doesn't have a BT capability built in it wouldn't request with content negotiation. e. From owner-atom-syntax@mail.imc.org Wed Oct 13 11:46: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 LAA09353 for ; Wed, 13 Oct 2004 11:46: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 i9DFamYr094825; Wed, 13 Oct 2004 08:36: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 i9DFamS8094824; Wed, 13 Oct 2004 08:36:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DFalVv094793 for ; Wed, 13 Oct 2004 08:36:47 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041013153701.38714.qmail@web41201.mail.yahoo.com> Received: from [67.160.80.192] by web41201.mail.yahoo.com via HTTP; Wed, 13 Oct 2004 08:37:00 PDT Date: Wed, 13 Oct 2004 08:37:00 -0700 (PDT) From: Dare Obasanjo Subject: Re: enclosures: types To: Antone Roundy , atom-syntax@imc.org In-Reply-To: <284F3CCA-1D29-11D9-A16E-003065EA6144@geckotribe.com> 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: --- Antone Roundy wrote: > > I have yet to have a customer complain. > I suspect they'd > be more likely to complain if I did an > almost-always-unnecessary HEAD > on every enclosure to see whether the (possibly > misconfigured) server > agreed with the feed, since that would slow > performance. Actually according to other posts by Lucas in this thread the server will MOST LIKELY be misconfigured (didn't he throw out a number like 75%) so if you are going to go as far as making network connections you might as well do a GET and seek into the file to sniff what type it is since the MIME type returned by the HEAD request is likely to be wrong anyway. > For me and > mine, @type is a useful feature. If it is less > useful for some other > application, let that application HEAD the > enclosures. +1 ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Wed Oct 13 11:51: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 LAA09753 for ; Wed, 13 Oct 2004 11:51:46 -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 i9DFgEhE095533; Wed, 13 Oct 2004 08:42:14 -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 i9DFgEtn095532; Wed, 13 Oct 2004 08:42:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DFgD7e095519 for ; Wed, 13 Oct 2004 08:42:13 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041013154227.74104.qmail@web41202.mail.yahoo.com> Received: from [67.160.80.192] by web41202.mail.yahoo.com via HTTP; Wed, 13 Oct 2004 08:42:27 PDT Date: Wed, 13 Oct 2004 08:42:27 -0700 (PDT) From: Dare Obasanjo Subject: Re: enclsoures: multipile enclosures in an entry To: lucas@gonze.com, Eric Scheid Cc: Atom Syntax In-Reply-To: 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: --- Lucas Gonze wrote: > > I'd say again: there's no usecase for this; if there > were it could be > satisfied within existing web architecture by > sending preferred types in > the Accept header; if there is really a pressing > reason to do this then > Atom is slipping into playlist functionality and > should start by looking > for a playlist format that already solves the > problem. Atom is a content syndication format. Music files are content. Throwing up a playlist on my site and having folks subscribe to it either directly or indirectly (i.e. an MP3 blog) is syndication. Sounds like a use case for Atom. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Oct 13 12:10:49 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 MAA11259 for ; Wed, 13 Oct 2004 12:10:48 -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 i9DFvYg4097292; Wed, 13 Oct 2004 08:57: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 i9DFvYRd097291; Wed, 13 Oct 2004 08:57:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DFvXo3097281 for ; Wed, 13 Oct 2004 08:57:33 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id IAA17727 for ; Wed, 13 Oct 2004 08:57:46 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id IAA10393 for ; Wed, 13 Oct 2004 08:57:37 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Wed, 13 Oct 2004 08:57:37 -0700 Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9DFuahc022458 for ; Wed, 13 Oct 2004 08:56:36 -0700 (PDT) Date: Wed, 13 Oct 2004 09:00:28 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: enclosures: types Message-ID: <36EF1CA539DF453680E09AA5@diva.verity.com> In-Reply-To: References: <7CADBE26-1C81-11D9-B530-003065EA6144@geckotribe.com> <416C3653.4040506@intertwingly.net> <036b01c4b09a$cdbc0500$200ca8c0@wkearney.com> <1f2ed5cd0410130349e5238db@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, October 13, 2004 10:37:10 AM -0400 Lucas Gonze wrote: > The situation is much worse for media files, because: > > 1) proliferation of media formats means that there are more mime types for > front line coders to learn. > > 2) the major vendors (Apple, MS, Real) are in a standards war and > see open standards like MIME as being in their competitors' interests. > > 3) a large portion of media files are served by proprietary servers that > ship misconfigured. I'd guess that 75% of Windows Media files are > served as text/plain. No, the situation is bad because Microsoft Internet Explorere ignores the content-type and dispatches on file extension. That means that it works in IE even when misconfigured, so there is little pressure to fix busted websites. This isn't a new problem. Most HTML files don't declare their encoding because Netscape Navigator had an encoding guesser. Past bad behavior is not a good reason for Atom to do it wrong. MIME content-type hints are useful, but they should only be hints. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Oct 13 12:26:55 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 MAA12945 for ; Wed, 13 Oct 2004 12:26:54 -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 i9DGHZt1099564; Wed, 13 Oct 2004 09:17:35 -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 i9DGHZHk099563; Wed, 13 Oct 2004 09:17:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGHX8U099547 for ; Wed, 13 Oct 2004 09:17:33 -0700 (PDT) (envelope-from lists@debpro.webcom.dk) Received: from [192.168.130.100] (0x5358d5cb.albnxx16.adsl-dhcp.tele.dk [83.88.213.203]) by pfepa.post.tele.dk (Postfix) with ESMTP id EEE8F47FE33 for ; Wed, 13 Oct 2004 18:17:48 +0200 (CEST) Message-ID: <416D552B.3030607@debpro.webcom.dk> Date: Wed, 13 Oct 2004 18:17:47 +0200 From: Jacob Larsen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: The like of =?ISO-8859-1?Q?RSS=B4_ttl=2C_skipHours_or_sk?= =?ISO-8859-1?Q?ipDays?= 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 Does Atom have the like of RSSŽ ttl, skipHours or skipDays? Thanks, Jacob From owner-atom-syntax@mail.imc.org Wed Oct 13 12:27:09 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 MAA13002 for ; Wed, 13 Oct 2004 12:27: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 i9DGFnK0099373; Wed, 13 Oct 2004 09:15:49 -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 i9DGFn6L099372; Wed, 13 Oct 2004 09:15:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGFmPa099365 for ; Wed, 13 Oct 2004 09:15:48 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id D49B3489D9; Wed, 13 Oct 2004 11:36:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DFZgu22870; Wed, 13 Oct 2004 11:35:42 -0400 (EDT) Date: Wed, 13 Oct 2004 11:35:42 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: enclosures: types In-Reply-To: <284F3CCA-1D29-11D9-A16E-003065EA6144@geckotribe.com> Message-ID: References: <284F3CCA-1D29-11D9-A16E-003065EA6144@geckotribe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Wednesday, October 13, 2004, at 08:42 AM, Lucas Gonze wrote: >> That's why YAGNI has been my mantra. The type attribute introduces bugs >> but not features. On Wed, 13 Oct 2004, Antone Roundy wrote: > Crappy feeds introduce bugs. A few people on this list have chanted in > opposition to your mantra, and my opinion harmonizes with theirs. The chanting preceded the mantra, so it can't have been in opposition. Also, please be careful about the flamish tone. > My > application, CaRP, which only uses image/gif and image/jpeg enclosures, uses > the type attribute to decide whether to try displaying an enclosure. I have > yet to have a customer complain. I suspect they'd be more likely to complain > if I did an almost-always-unnecessary HEAD on every enclosure to see whether > the (possibly misconfigured) server agreed with the feed, since that would > slow performance. For me and mine, @type is a useful feature. If it is less > useful for some other application, let that application HEAD the enclosures. Can you talk about your application more? Why put images in enclosures rather than in content? This is unconventional, so the first thing to figure out is whether your usage matches up with what we're trying to enable. - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 12:37: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 MAA14070 for ; Wed, 13 Oct 2004 12:37: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 i9DGPUHk000667; Wed, 13 Oct 2004 09:25:30 -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 i9DGPUEl000666; Wed, 13 Oct 2004 09:25:30 -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 i9DGPUfV000644 for ; Wed, 13 Oct 2004 09:25:30 -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 <2004101316254301600c2p3te>; Wed, 13 Oct 2004 16:25:43 +0000 Date: Wed, 13 Oct 2004 10:25:42 -0600 Subject: Re: enclosures: types 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: Message-Id: <86E22186-1D34-11D9-A16E-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, October 13, 2004, at 09:35 AM, Lucas Gonze wrote: > Can you talk about your application more? Why put images in > enclosures rather than in content? This is unconventional, so the > first thing to figure out is whether your usage matches up with what > we're trying to enable. > My application is a feed consumer (it displays feeds on websites), not a publisher. It's consuming images that other publishers, for whatever reason, put into enclosures. I'd guess that the decision whether to put it in content or an enclosure is based on a few factors: 1) Whether the publisher wants to dictate how the image is displayed in relation to the item or whether they want the consumer to be able to configure that. I find it useful to have them separated so that, for example, the feed can be displayed in a table with images in the first column and title/link and descriptions in the second. 2) Some consuming applications may strip out inline images from content. Putting it into an enclosure MIGHT increase the probability of the application displaying it, since they more control over presentation (see the second sentence above for an example). 3) If the content is plain text, the image can't be included in it. From owner-atom-syntax@mail.imc.org Wed Oct 13 12:58: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 MAA15514 for ; Wed, 13 Oct 2004 12:58: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 i9DGmXDe003819; Wed, 13 Oct 2004 09:48: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 i9DGmX60003818; Wed, 13 Oct 2004 09:48:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DGmXJP003787 for ; Wed, 13 Oct 2004 09:48:33 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA20307 for ; Wed, 13 Oct 2004 09:48:47 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA16467 for ; Wed, 13 Oct 2004 09:48:46 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Wed, 13 Oct 2004 09:48:46 -0700 Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9DGljhc022655 for ; Wed, 13 Oct 2004 09:47:45 -0700 (PDT) Date: Wed, 13 Oct 2004 09:51:37 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Message-ID: <7CE6C37A5AE42000E7889CA8@diva.verity.com> In-Reply-To: <416D552B.3030607@debpro.webcom.dk> References: <416D552B.3030607@debpro.webcom.dk> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DGmXJP003812 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit --On Wednesday, October 13, 2004 06:17:47 PM +0200 Jacob Larsen wrote: > > Does Atom have the like of RSSŽ ttl, skipHours or skipDays? Not yet. I've volunteered to write a proposal for Expires, which accomplishes all that with less fuss and a better mapping to HTTP caching. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Oct 13 13:31:59 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 NAA17927 for ; Wed, 13 Oct 2004 13:31:59 -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 i9DHK6ml009185; Wed, 13 Oct 2004 10:20: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 i9DHK63Q009182; Wed, 13 Oct 2004 10:20:06 -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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHK5Rk009168 for ; Wed, 13 Oct 2004 10:20:06 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so833349rnl for ; Wed, 13 Oct 2004 10:20:22 -0700 (PDT) Received: by 10.38.126.4 with SMTP id y4mr2991671rnc; Wed, 13 Oct 2004 10:20:22 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Wed, 13 Oct 2004 10:20:22 -0700 (PDT) Message-ID: <540e37320410131020f324bab@mail.gmail.com> Date: Wed, 13 Oct 2004 12:20:22 -0500 From: "Roger B." Reply-To: "Roger B." To: lucas@gonze.com Subject: Re: enclosures: types Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <284F3CCA-1D29-11D9-A16E-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Can you talk about your application more? Why put images in enclosures > rather than in content? This is unconventional... Lucas: No, it isn't. Flickr does the same thing, for example. As for why... so the user can download the image, not a chunk of HTML that references it. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Wed Oct 13 14:06:27 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 OAA20591 for ; Wed, 13 Oct 2004 14:06:27 -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 i9DHtfu7014254; Wed, 13 Oct 2004 10:55: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 i9DHtfP3014253; Wed, 13 Oct 2004 10:55:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DHtdXw014245 for ; Wed, 13 Oct 2004 10:55:40 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 1BB4A491F8 for ; Wed, 13 Oct 2004 13:42:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9DHgFm02454 for ; Wed, 13 Oct 2004 13:42:15 -0400 (EDT) Date: Wed, 13 Oct 2004 13:42:15 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: atom-syntax@imc.org Subject: enclosures: usecases Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 1) For Flickr, the user can download the image, not a chunk of HTML that references it. 2) You have a portable MP3 player, and you have a feed which gives you MP3s to copy onto it. 3) You have a bandwidth limited feed reader. For example, over a mobile phone, where you are charged for bandwidth. 4) You have a portable hard drive which you use to carry source code, and you have a feed containing diffs. 5) For very large images like the NASA P.O.T.D, the download time is high enough to want to prefetch. 6) Whether the publisher wants to dictate how the image is displayed in relation to the item or whether they want the consumer to be able to configure that. I find it useful to have them separated so that, for example, the feed can be displayed in a table with images in the first column and title/link and descriptions in the second. 7) Some consuming applications may strip out inline images from content. Putting it into an enclosure MIGHT increase the probability of the application displaying it, since they more control over presentation (see the second sentence above for an example). 8) If the content is plain text, the image can't be included in it. ........................................ Next is to ask whether an enclosure element and/or the type attribute is the best way to do these. Is there a more parsimonious solution using other Atom features, HTTP features, or layers higher in the stack than the feed format? - Lucas From owner-atom-syntax@mail.imc.org Wed Oct 13 15:26: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 PAA27299 for ; Wed, 13 Oct 2004 15:26:20 -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 i9DJGQ2V024473; Wed, 13 Oct 2004 12:16:26 -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 i9DJGQLJ024472; Wed, 13 Oct 2004 12:16:26 -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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DJGPaV024448 for ; Wed, 13 Oct 2004 12:16:26 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so274968rnk for ; Wed, 13 Oct 2004 12:16:40 -0700 (PDT) Received: by 10.38.179.17 with SMTP id b17mr2006400rnf; Wed, 13 Oct 2004 12:16:40 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 12:16:40 -0700 (PDT) Message-ID: <1f2ed5cd0410131216463f0997@mail.gmail.com> Date: Wed, 13 Oct 2004 21:16:40 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Walter Underwood Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Cc: atom-syntax@imc.org In-Reply-To: <7CE6C37A5AE42000E7889CA8@diva.verity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <416D552B.3030607@debpro.webcom.dk> <7CE6C37A5AE42000E7889CA8@diva.verity.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DJGQaV024467 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Does anyone have any data relating to the use of ttl etc and the syn module? Do some/all/most feed generators include them (usefully)? Do some/all/most aggegators use them (usefully)? "Expires" does seem a reasonable way forward, but when it comes to performance, profiling stats are usually more accurate than intuition. Cheers, Danny. On Wed, 13 Oct 2004 09:51:37 -0700, Walter Underwood wrote: > > --On Wednesday, October 13, 2004 06:17:47 PM +0200 Jacob Larsen wrote: > > > > Does Atom have the like of RSSŽ ttl, skipHours or skipDays? > > Not yet. I've volunteered to write a proposal for Expires, which > accomplishes all that with less fuss and a better mapping to > HTTP caching. > > wunder > -- > Walter Underwood > Principal Architect > Verity Ultraseek > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 16:21: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 QAA03147 for ; Wed, 13 Oct 2004 16:21:50 -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 i9DKAj6C032220; Wed, 13 Oct 2004 13:10:45 -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 i9DKAjOv032219; Wed, 13 Oct 2004 13:10:45 -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 ESMTP id i9DKAglR032204 for ; Wed, 13 Oct 2004 13:10:43 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so278234rnk for ; Wed, 13 Oct 2004 13:11:02 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr2026622rnf; Wed, 13 Oct 2004 13:11:02 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 13:11:02 -0700 (PDT) Message-ID: <1f2ed5cd041013131164a6ea20@mail.gmail.com> Date: Wed, 13 Oct 2004 22:11:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: enclsoures: multipile enclosures in an entry Cc: lucas@gonze.com, Eric Scheid , Atom Syntax In-Reply-To: <20041013154227.74104.qmail@web41202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041013154227.74104.qmail@web41202.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 13 Oct 2004 08:42:27 -0700 (PDT), Dare Obasanjo wrote: > Atom is a content syndication format. Music files are > content. If that's the definition we're following, then to fulfil the charter we'll also have to figure out how to do remote audio and video editing using the protocol too. I would guess to the level of splicing would be appropriate. Should be fun, though this project may take a while longer than initially anticipated. Alternately we could assume that "content" in the charter refers to text-based formats. Throwing up a playlist on my site and having > folks subscribe to it either directly or indirectly > (i.e. an MP3 blog) is syndication. > > Sounds like a use case for Atom. It does, but looking at the list of playlists formats there's a great risk of inventing Yet Another Playlist format. I would suggest working with the people [1] already developing openly in this domain to see if Atom core can feasibly support binary media playlist syndication (i.e. as bugfixed ). Everything else should go in an extension, left to the domain experts. I suspect the typing issue in link->content vs. link->meta->content will need to be tackled on some front sometime whatever we do. Cheers, Danny. [1] http://playlist.musicbrainz.org/playlist/moin.cgi/FrontPage -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 16:53:23 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 QAA06058 for ; Wed, 13 Oct 2004 16:53:22 -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 i9DKfUuP036585; Wed, 13 Oct 2004 13:41:30 -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 i9DKfUnt036584; Wed, 13 Oct 2004 13:41:30 -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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DKfT3m036570 for ; Wed, 13 Oct 2004 13:41:29 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so280292rnk for ; Wed, 13 Oct 2004 13:41:49 -0700 (PDT) Received: by 10.38.179.57 with SMTP id b57mr2038069rnf; Wed, 13 Oct 2004 13:41:49 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 13:41:49 -0700 (PDT) Message-ID: <1f2ed5cd0410131341276f29ad@mail.gmail.com> Date: Wed, 13 Oct 2004 22:41:49 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: enclosures: types Cc: lucas@gonze.com, James Aylett , Atom Syntax In-Reply-To: <416D4366.2000405@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041013094353.GB5713@tartarus.org> <416D4366.2000405@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 13 Oct 2004 11:01:58 -0400, Robert Sayre wrote: > > Lucas Gonze wrote: > > > > > No, but HEAD is even smaller. > > > > What's missing in this conversation is an application requirement. What > > would the client do differently for SVG than BitTorrent, and why does it > > belong at this layer? That's why YAGNI has been my mantra. The type > > attribute introduces bugs but not features. I don't think YAGNI is an appropriate pattern for spec development, but still I'm not sure putting this kind of data in an attribute is advisable. > I would agree with you if HTTP was perfect, but HEAD requests do have a > cost, and not all resources respond to HEAD requests accurately. > > Let's say I'm subscribed to 1000 feeds in Project D.U.[0] or something > similar, and I have it configured to show me .mp3 enclosures in a > special pane (I don't want .wma .ra files). Declaring the type in advance is only useful if it makes a significant improvement in performance and/or reduction in complexity in a large proportion of cases. Even then, that only works if the data passed along this way is going to be significantly more accurate than the data obtained by other means. Where is the publishing tool going to get its information from? Is the aggregator supposed > HEAD every single enclosure link to find out which ones are mp3s? Possibly, yes, if that's the way the trade-off goes. At least one of the costs of HEADs (bandwidth) is proportionately reduced when dealing with big media files. > I think the type attribute is useful metadata in the same sense that the > title attribute is. If we omit it, we'll just see stuff like this: > > > > That's something we often see in HTML. There's your use case. Well, not really because you can still do a HEAD and it doens't make the in-content statement any more reliable. If the type attribute inline will be non-redundant, accurate and useful information then let's have it . But adding another unreliable piece of information will just offer another avenue for error. So far I don't think all the angles have yet been convincingly covered. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 17:04:09 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 RAA07577 for ; Wed, 13 Oct 2004 17:04: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 i9DKtjxY038362; Wed, 13 Oct 2004 13:55:45 -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 i9DKtjUD038361; Wed, 13 Oct 2004 13:55:45 -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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DKtif5038355 for ; Wed, 13 Oct 2004 13:55:45 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so281215rnk for ; Wed, 13 Oct 2004 13:56:03 -0700 (PDT) Received: by 10.38.8.80 with SMTP id 80mr2074707rnh; Wed, 13 Oct 2004 13:56:02 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 13 Oct 2004 13:56:02 -0700 (PDT) Message-ID: <1f2ed5cd04101313565c7e19d5@mail.gmail.com> Date: Wed, 13 Oct 2004 22:56:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: "Roger B." Subject: Re: enclosures: types Cc: lucas@gonze.com, atom-syntax@imc.org In-Reply-To: <540e37320410131020f324bab@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <284F3CCA-1D29-11D9-A16E-003065EA6144@geckotribe.com> <540e37320410131020f324bab@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 13 Oct 2004 12:20:22 -0500, Roger B. wrote: > > > Can you talk about your application more? Why put images in enclosures > > rather than in content? This is unconventional... > > Lucas: No, it isn't. Flickr does the same thing, for example. As for > why... so the user can download the image, not a chunk of HTML that > references it. Do you happen to know offhand how Flickr handles media typing? -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 13 17:05:38 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 RAA07824 for ; Wed, 13 Oct 2004 17:05:38 -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 i9DKtQuw038318; Wed, 13 Oct 2004 13:55:26 -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 i9DKtQwk038317; Wed, 13 Oct 2004 13:55:26 -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 i9DKtPKi038311 for ; Wed, 13 Oct 2004 13:55:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CHq9t-00047l-EL; Wed, 13 Oct 2004 20:55:41 +0000 Message-ID: <416D964F.2040607@franklinmint.fm> Date: Wed, 13 Oct 2004 16:55:43 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers , Atom Syntax Subject: Re: enclosures: types References: <20041013094353.GB5713@tartarus.org> <416D4366.2000405@franklinmint.fm> <1f2ed5cd0410131341276f29ad@mail.gmail.com> In-Reply-To: <1f2ed5cd0410131341276f29ad@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > >>I think the type attribute is useful metadata in the same sense that the >>title attribute is. If we omit it, we'll just see stuff like this: >> >> >> >>That's something we often see in HTML. There's your use case. > > > Well, not really because you can still do a HEAD and it doens't make > the in-content statement any more reliable. Then why does HTML have @type? > > If the type attribute inline will be non-redundant, accurate and > useful information then let's have it Ha! Which part of the Atom format makes that guarantee? @type is there to present alternatives, just like @title. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Oct 13 17:26:55 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 RAA12656 for ; Wed, 13 Oct 2004 17:26:54 -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 i9DLFfsl041291; Wed, 13 Oct 2004 14:15: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 i9DLFfXO041290; Wed, 13 Oct 2004 14:15:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DLFeO6041282 for ; Wed, 13 Oct 2004 14:15:40 -0700 (PDT) (envelope-from wkearney@syndic8.com) Received: (qmail 18465 invoked from network); 13 Oct 2004 21:15:58 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Oct 2004 21:15:58 -0000 Message-ID: <058701c4b169$d5c42320$200ca8c0@wkearney.com> From: "Bill Kearney" To: "Eric Scheid" , "Atom Syntax" References: Subject: Re: [RSS-DEV] Re: Atom and RDF Date: Wed, 13 Oct 2004 17:15:58 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > Uh, that's sort of the entire reason for using the attributes, isn't it? > not necessarily. > if a feed contained these elements: > > My point about attributes was within the context of an enclosure element. It's use of type and size are among the reasons to use attributes. Type alone is indeed helpful, other data helps too. The size being that of the end-result data not the interim pointer URI for a p2p network. While it migth, perhaps, be interesting to know the size of the p2p pointer file it's probably not going to be very useful in making any decisions related to the handling of the target data. Knowing the size of the torrent link would be nearly as useless as knowing the size of an HTML index page that contained links to other things. > Only when attempting to download the "application/mpeg" enclosure might the > aggregator be faced with handling an inconsistency. It doesn't care if the > "audio/midi" file is served as "text/plain" because it will never look at > it. Well, yeah, that's sort of obvious. It's in the question of whether or not, or how to handle retrieval (if at all) that added metadata helps the decision-making. I also think there's a difference between the semantics of an enclosure versus that of streamed data or something that provides an alternative representation of the data. An audio recording of the same data presents an interesting question. Is it an enclosure or is it an alternative? The idea of an enclosure is to allow an item to indicate that it's got some sort of extra 'payload' that can be downloaded locally, perhaps at a different interval or during off-peak times. Off-peak being it's own big of ambiguity as well. Is it off-peak for the client (as it's assumed now) or is it off-peak for the serving resource. I could well see situations where some might consider the latter might to be useful. The original use case for enclosures in RSS was to push music and videos out to the users but not bog down their immediate daytime downloading experience. -Bill Kearney From owner-atom-syntax@mail.imc.org Wed Oct 13 20:33:43 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 UAA28484 for ; Wed, 13 Oct 2004 20:33:43 -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 i9E0Ox0g067700; Wed, 13 Oct 2004 17:24:59 -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 i9E0Oxgd067699; Wed, 13 Oct 2004 17:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E0OvEG067644 for ; Wed, 13 Oct 2004 17:24:58 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 14 Oct 2004 10:24:56 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Oct 2004 10:24:44 +1000 Subject: Re: enclosures: types From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/10/04 3:32 AM, "Lucas Gonze" wrote: >>> Can you talk about your application more? Why put images in enclosures >>> rather than in content? >> >> so they can be pre-cached? >> >> or do you mean in content/@src? > > Oops. Yup. That makes a little more sense ... however the image would be the only content then, and there would be no commentary for that image. There's a narrow use case where could be used, but that doesn't cater to the use case of the image being not the whole story, nor the use case of multiple images provided as enclosures to a single entry (where you would have much more commentary, and the images are not "alternatives" to each other either). e. From owner-atom-syntax@mail.imc.org Wed Oct 13 20:42: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 UAA29154 for ; Wed, 13 Oct 2004 20:42:45 -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 i9E0YixZ068849; Wed, 13 Oct 2004 17:34: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 i9E0YiFm068848; Wed, 13 Oct 2004 17:34:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E0YhHF068832 for ; Wed, 13 Oct 2004 17:34:43 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9E0Z4ui007754 for ; Wed, 13 Oct 2004 18:35:04 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5J004W5TMG43@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 13 Oct 2004 18:35:04 -0600 (MDT) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5J00CB9TMFE1@mail.sun.net> for atom-syntax@imc.org; Wed, 13 Oct 2004 18:35:04 -0600 (MDT) Date: Wed, 13 Oct 2004 17:35:24 -0700 From: Tim Bray Subject: atom:link state of play To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9E0YhHF068841 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I have just read all the link-related Paces, both those currently on the Public Issues List and the various guerilla offerings that have been provoked by the discussion, and then I ran through the mailing list archive again. My overview of the state of play, which anyone should feel free to correct if it's wrong: 1. Pace Statuses The following Paces have been convincingly shouted down and should be closed PaceLinkAttrDefaults PaceLinkRelMechanism (ouf, I think this set a record in the -1 count, and I didn't even get around to putting my -1 in) The following Paces are clinging to life, have a single -1 but aren't being strung up to the rafters by a howling mob: PaceLinkConstruct (adds rev="comment|update|replaces") PaceLinkDelicious (add "related" and "about" to @rel values) PaceLinkParent (add "in-reply-to" to @rel values) PaceReplaceLinkElement (no @rel, , , , etc...) The following Pace has, I think, a certain amount of positive buzz, with some +1's and some comments saying "OK, but improve it this way or that": PaceLinkPurpose 2. Service Attributes There's a PaceServiceElement out there that takes the service.this and service.that out of the repertoire of @rel and adds or some such, and it's got enough +1's that I was convinced it had already been accepted, but I guess not. But I bet it will be, so it might be reasonable to omit the service.* values in discussion of @rel possibilities. 3. atom:link omission Asbjørn posted PaceOptionalAlternateLink which proposes to make atom:link optional. Sam Ruby proposed a variant where it's optional unless isn't there, in which case it's required. Not relevant in the short term, but my spidey-sense tells me these will probably get accepted, because we went over this in the mailing list some time ago and there wasn't much pushback. 4. Extensibility Ladies and gentlemen, this is a horrible mess! The following mechanisms are on the table for an extensible link construct: 1. @rel values from keyword list hardwired in the spec (current draft) 2. @rel values have prefixes from an IANA registry (PaceLinkRelPrefixReg) 3. @rel values are qnames (PaceLinkRelMechanism) 4. @rel values are URIs (PaceLinkRelUri) 5. anything with an atom:href attribute is a link (PaceRelationshipConstruct) 6. a general construct-signaling mechanism (PaceConstructAttribute). [Steve Newcomb, where are you? This idea is at least 15 years old, it's called "Architectural Forms" and is an ISO Standard, see Annex A of ISO 10744] 7. Invent a new element for each type of link (PaceReplaceLinkElement) It is painfully obvious that there is no consensus on how to do extensibility. Furthermore, it is painfully obvious that there is no consensus as to what basic flavors of link, if any, should be cooked into the spec (or the IANA registry, or given well-known URIs, or whatever). Furthermore, I challenged the WG (http://imc.org/atom-syntax/mail-archive/msg10471.html) as to whether we really had to do extensible generalized links. It got one solid "yes" from Danny Ayers (but Rob Sayre pushed back hard), one sort-kinda-yes from Dare Obsanjo ("I'm partial to allowing some form of extensibility in link constructs IFF a clear and concise definition of what it means to be 'link' makes it into the spec.") and one interesting counter-proposal from Sayre (http://imc.org/atom-syntax/mail-archive/msg10481.html) which I don't think is a Pace yet. 5. Conclusion SO, if I had to make consensus call right now based on where we are right now, it would be based on "what's left over after you remove everything that's been objected to" and it would look something like: 1. The only defined value for @rel on atom:link would be "alternate" and that would be the default 2. the material would be moved from the protocol to the format draft 3. The service.* stuff would go into a different element or set of elements 4. atom:link would be omissable (maybe required if atom:content isn't there) 6. Recommendations People who want some sort of an extensible link framework REALLY NEED to go off in a corner and agree on a recipe and see if they can build consensus around one thing. I would also point out that if it's not in Atom 1.0, well, it could be added later. Also, I think Rob Sayre's extensibility idea needs to be cooked into a Pace. -Tim From owner-atom-syntax@mail.imc.org Wed Oct 13 21:18:16 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 VAA01607 for ; Wed, 13 Oct 2004 21:18:15 -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 i9E1AnSL073808; Wed, 13 Oct 2004 18:10:49 -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 i9E1An5n073807; Wed, 13 Oct 2004 18:10:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E1AnSL073798 for ; Wed, 13 Oct 2004 18:10:49 -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 (sccrmhc11) with SMTP id <20041014011104011007ae7fe>; Thu, 14 Oct 2004 01:11:05 +0000 Date: Wed, 13 Oct 2004 19:11:03 -0600 Subject: Re: atom:link state of play 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: Message-Id: 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, October 13, 2004, at 06:35 PM, Tim Bray wrote: > The following Paces are clinging to life, have a single -1 but aren't > being strung up to the rafters by a howling mob: ... > PaceLinkDelicious (add "related" and "about" to @rel values) I'll give this a +1. > 2. Service Attributes > > ... PaceServiceElement ... I was convinced it had already been > accepted, but I guess not. I thought it had been too...perhaps based on the fact that it's in the "accepted" part of the issues list. Did it get moved there accidentally? > 4. Extensibility ... > Furthermore, I challenged the WG > (http://imc.org/atom-syntax/mail-archive/msg10471.html) as to whether > we really had to do extensible generalized links. It got one solid > "yes" from Danny Ayers (but Rob Sayre pushed back hard), one > sort-kinda-yes from Dare Obsanjo ("I'm partial to allowing some form > of extensibility in link constructs IFF a clear and concise definition > of what it means to be 'link' makes it into the spec.") and one > interesting counter-proposal from Sayre > (http://imc.org/atom-syntax/mail-archive/msg10481.html) which I don't > think is a Pace yet. I'm with Dare on this one. From time to time, people come up with ideas for new @rel values, some of which don't (assuming PaceLinkPurpose) don't belong in , but some of which do and would be useful. I think the probability of people coming up with other good ideas is high enough that building extensibility in would be good...as long as we tighten the definition of Link Constructs. From owner-atom-syntax@mail.imc.org Wed Oct 13 21:27:36 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 VAA02433 for ; Wed, 13 Oct 2004 21:27: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 i9E1KkYK075088; Wed, 13 Oct 2004 18:20: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 i9E1KkF1075087; Wed, 13 Oct 2004 18:20:46 -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 i9E1KkgQ075080 for ; Wed, 13 Oct 2004 18:20:46 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CHuIk-0001e4-OB; Thu, 14 Oct 2004 01:21:06 +0000 Message-ID: <416DD47F.1040502@franklinmint.fm> Date: Wed, 13 Oct 2004 21:21:03 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray , Atom Syntax Subject: Re: atom:link state of play References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > Also, I think Rob Sayre's extensibility idea needs to be cooked into a > Pace. I have too many pans in the fire right now, so I asked Danny to help me get it started. He agreed, so we are working a notion of properties and reexamining GRDDLish stuff in the process. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Oct 13 22:03:49 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 WAA04648 for ; Wed, 13 Oct 2004 22:03:49 -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 i9E1stTZ079458; Wed, 13 Oct 2004 18:54: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 i9E1stHc079457; Wed, 13 Oct 2004 18:54:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E1srkC079451 for ; Wed, 13 Oct 2004 18:54:54 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 14 Oct 2004 11:55:25 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Oct 2004 11:55:12 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/10/04 10:35 AM, "Tim Bray" wrote: > Furthermore, I challenged the WG > (http://imc.org/atom-syntax/mail-archive/msg10471.html) as to whether > we really had to do extensible generalized links. I don't know how I missed that. I've been a proponent for allowing exstensibility in link @rel from the beginning and I've been coming up with new @rel values as a side effect of other discussions. Just yesterday I wrote where, of course, "playlist" could be "ns:playlist", "prefix.playlist", or whatever according whichever extensibility model we go with. other @rel values which are not in the core list of enumerated types include comments versions trackbacks pings components licence prefetch and probably some others I've forgotten about. The point is that very few of these were in the original enumerated list. They were thought up after the fact. Limiting link/@rel to an known set would stifle innovation in this form. e. From owner-atom-syntax@mail.imc.org Wed Oct 13 22:26:23 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 WAA06489 for ; Wed, 13 Oct 2004 22:26:22 -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 i9E2JDl4083332; Wed, 13 Oct 2004 19:19: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 i9E2JDgE083331; Wed, 13 Oct 2004 19:19:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41202.mail.yahoo.com (web41202.mail.yahoo.com [66.218.93.35]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9E2JCe2083315 for ; Wed, 13 Oct 2004 19:19:12 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041014021929.9106.qmail@web41202.mail.yahoo.com> Received: from [67.168.40.45] by web41202.mail.yahoo.com via HTTP; Wed, 13 Oct 2004 19:19:29 PDT Date: Wed, 13 Oct 2004 19:19:29 -0700 (PDT) From: Dare Obasanjo Subject: Re: atom:link state of play To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > other @rel values which are not in the core list of > enumerated types include > > comments > versions > trackbacks > pings > components > licence > prefetch A bunch of link types with disimilar semantics. Unless there's a clearly defined mechanism for telling clients how to distinguish between the various link types or a reasonable default behavior can be picked for ALL links I don't see how this is any better than allowing namespaced extension elements. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Wed Oct 13 22:55:50 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 WAA09187 for ; Wed, 13 Oct 2004 22:55:49 -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 i9E2msAt086904; Wed, 13 Oct 2004 19:48:54 -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 i9E2msRH086903; Wed, 13 Oct 2004 19:48:54 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E2mqC4086894 for ; Wed, 13 Oct 2004 19:48:53 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Wed, 13 Oct 2004 19:49:31 -0700 To: Atom Syntax From: Paul Hoffman / IMC Subject: Re: atom:link state of play 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:55 AM +1000 10/14/04, Eric Scheid wrote: >The point is that very few of these were in the original enumerated list. >They were thought up after the fact. Limiting link/@rel to an known set >would stifle innovation in this form. Would you (and others) be happy with a simple IANA registry that gets filled in when there is a standards-track RFC. It would start with "alternate -> RFC {ournumber}", and entries would be added as the RFCs issued. FWIW, it would be perfectly permissible for a single RFC to be the registration for multiple new values. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Oct 13 23:09:55 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 XAA09964 for ; Wed, 13 Oct 2004 23:09:55 -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 i9E2xdhe087940; Wed, 13 Oct 2004 19:59:39 -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 i9E2xdOO087939; Wed, 13 Oct 2004 19:59:39 -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 i9E2xdqX087919 for ; Wed, 13 Oct 2004 19:59:39 -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 <2004101402595501300t87n7e>; Thu, 14 Oct 2004 02:59:55 +0000 Date: Wed, 13 Oct 2004 20:59:54 -0600 Subject: Re: atom:link state of play 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: <20041014021929.9106.qmail@web41202.mail.yahoo.com> Message-Id: <1FDD0E1A-1D8D-11D9-A16E-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, October 13, 2004, at 08:19 PM, Dare Obasanjo wrote: > --- Eric Scheid wrote: >> other @rel values which are not in the core list of >> enumerated types include >> >> comments >> versions >> trackbacks >> pings >> components >> licence >> prefetch > > A bunch of link types with disimilar semantics. Unless > there's a clearly defined mechanism for telling > clients how to distinguish between the various link > types or a reasonable default behavior can be picked > for ALL links I don't see how this is any better than > allowing namespaced extension elements. > I can conceive of comments, versions, trackbacks, pings and maybe license being handled quite similarly (on click/select/whatever, display another newsfeed or a web page), though I'd have to see definitions of them to be sure they mean what I think they mean. I have no idea what is meant by components, so have no comment on that. Prefetch seems ... a little out of place. Not that an element with that purpose is necessarily a bad idea, but it doesn't fit my mental model of a Link Construct. From owner-atom-syntax@mail.imc.org Wed Oct 13 23:25: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 XAA11956 for ; Wed, 13 Oct 2004 23:25: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 i9E3IPMq090294; Wed, 13 Oct 2004 20:18:25 -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 i9E3IPok090293; Wed, 13 Oct 2004 20:18:25 -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 i9E3IPoR090283 for ; Wed, 13 Oct 2004 20:18:25 -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 <2004101403184201300t4mppe>; Thu, 14 Oct 2004 03:18:42 +0000 Date: Wed, 13 Oct 2004 21:18:41 -0600 Subject: Re: atom:link state of play 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: Message-Id: 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, October 13, 2004, at 08:49 PM, Paul Hoffman / IMC wrote: > At 11:55 AM +1000 10/14/04, Eric Scheid wrote: >> The point is that very few of these were in the original enumerated >> list. >> They were thought up after the fact. Limiting link/@rel to an known >> set >> would stifle innovation in this form. > > Would you (and others) be happy with a simple IANA registry that gets > filled in when there is a standards-track RFC. It would start with > "alternate -> RFC {ournumber}", and entries would be added as the RFCs > issued. FWIW, it would be perfectly permissible for a single RFC to be > the registration for multiple new values. Adding this to the list of proposals and restating it in terms of difficulty of adding new values, we have: 1) Impossible: the list is closed (actually, this is not proposed) 2) Extremely difficult: get it added to the Atom core spec 3) Quite difficult: get it into an RFC 4) Troublesome: register each value 5) Bothersome but doable: register a prefix 6) Easy: make your own extension I think I might be satisfied by #3, with the following conditions and reason: Conditions: 1) The Atom WG's charter is extended ("Extension development is not included in this charter.") to cover ongoing discussion of proposed additions. Otherwise, I think "quite difficult" would turn into "extremely difficult" or worse. 2) The definition of a Link Construct is tightened (otherwise, I much don't care what else happens with it) Reason: Unless people coming up with new @rel values have a tight definition of a Link Construct firmly in mind, it's not unlikely that people will create new values which don't fit the definition that...I hope we come up with. If that happens, Link Constructs as an extensibility point could become useless. It may be that "market" forces would kick things in line (if aggregators process extension links in a standard way, and refuse to make exceptions for things that don't belong there), but I'm not sure we can count on that. So there needs to be SOME barrier. It's just a question of how high it should be. I think I may be arguing against a few of my own proposals here... From owner-atom-syntax@mail.imc.org Wed Oct 13 23:29:22 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 XAA12369 for ; Wed, 13 Oct 2004 23:29:22 -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 i9E3MNx4090705; Wed, 13 Oct 2004 20:22: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 i9E3MNV4090704; Wed, 13 Oct 2004 20:22:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E3MMgG090686 for ; Wed, 13 Oct 2004 20:22:23 -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 (rwcrmhc13) with SMTP id <2004101403223901500n2stle>; Thu, 14 Oct 2004 03:22:40 +0000 Date: Wed, 13 Oct 2004 21:22:38 -0600 Subject: Re: atom:link state of play 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: Message-Id: <4CEEB034-1D90-11D9-A16E-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, October 13, 2004, at 08:49 PM, Paul Hoffman / IMC wrote: >> The point is that very few of these were in the original enumerated >> list. >> They were thought up after the fact. Limiting link/@rel to an known >> set >> would stifle innovation in this form. > > Would you (and others) be happy with a simple IANA registry that gets > filled in when there is a standards-track RFC. It would start with > "alternate -> RFC {ournumber}", and entries would be added as the RFCs > issued. FWIW, it would be perfectly permissible for a single RFC to be > the registration for multiple new values. > One more thing--there's an argument for not setting the bar too high: if it is too difficult to get new values officially recognized, we run the risk of people making up new values without going through the process. For this reason, it may be best to devise a mechanism that ensures (as much as possible) that we don't get naming collisions. What a dilemma. From owner-atom-syntax@mail.imc.org Wed Oct 13 23:57:50 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 XAA14438 for ; Wed, 13 Oct 2004 23:57:50 -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 i9E3mFrB094101; Wed, 13 Oct 2004 20:48: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 i9E3mFqr094098; Wed, 13 Oct 2004 20:48:15 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E3mDui094084; Wed, 13 Oct 2004 20:48:13 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4CEEB034-1D90-11D9-A16E-003065EA6144@geckotribe.com> References: <4CEEB034-1D90-11D9-A16E-003065EA6144@geckotribe.com> Date: Wed, 13 Oct 2004 20:48:51 -0700 To: Antone Roundy , atom-syntax@imc.org From: Paul Hoffman / IMC Subject: Re: atom:link state of play 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 9:18 PM -0600 10/13/04, Antone Roundy wrote: >1) Impossible: the list is closed (actually, this is not proposed) >2) Extremely difficult: get it added to the Atom core spec >3) Quite difficult: get it into an RFC >4) Troublesome: register each value >5) Bothersome but doable: register a prefix >6) Easy: make your own extension > >I think I might be satisfied by #3, with the following conditions and reason: > >Conditions: >1) The Atom WG's charter is extended ("Extension development is not >included in this charter.") to cover ongoing discussion of proposed >additions. Otherwise, I think "quite difficult" would turn into >"extremely difficult" or worse. We don't need to extend the Atom charter to do this, and in fact such an extension probably wouldn't happen. Typically in the IETF, mailing lists live long after the WG is closed down. If the IESG gets a proposal for a standards-track RFC with a new @rel value, the Apps AD will probably ping the list and say "Have you folks discussed this? Is it OK?" >2) The definition of a Link Construct is tightened (otherwise, I >much don't care what else happens with it) That's *always* a good idea. And your proposed text is... >One more thing--there's an argument for not setting the bar too >high: if it is too difficult to get new values officially >recognized, we run the risk of people making up new values without >going through the process. For this reason, it may be best to >devise a mechanism that ensures (as much as possible) that we don't >get naming collisions. What a dilemma. It's one we fight with in the IETF all the time. A standards-track RFC is probably a reasonable bar because the extension has to come up with a clear description of what you are supposed to do with the link; that kind of description easily fits into a standards-track RFC. I think of these like ESMTP extensions, of which there are many. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Oct 14 01:20: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 BAA20900 for ; Thu, 14 Oct 2004 01:20:15 -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 i9E5Ass3007293; Wed, 13 Oct 2004 22:10: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 i9E5AsfU007292; Wed, 13 Oct 2004 22:10:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E5Ar4U007009 for ; Wed, 13 Oct 2004 22:10:54 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 14 Oct 2004 15:09:56 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Oct 2004 15:09:43 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041014021929.9106.qmail@web41202.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/10/04 12:19 PM, "Dare Obasanjo" wrote: >> comments >> versions >> trackbacks >> pings >> components >> licence >> prefetch > > A bunch of link types with disimilar semantics. Unless > there's a clearly defined mechanism for telling > clients how to distinguish between the various link > types or a reasonable default behavior can be picked > for ALL links I don't see how this is any better than > allowing namespaced extension elements. they all have the same generic semantic: here is a resource which is related to the current entry, click the link to retrieve the resource. saying they have dissimilar semantics is like claiming the element in html is also broken because I could link to an RSS feed, a jpeg image, a quicktime movie, another html page, a gopher page, an ftp site, and SVG graphic, etc etc etc. Each one could be treated differently, but each one also has the same basic semantic. e. From owner-atom-syntax@mail.imc.org Thu Oct 14 01:49: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 BAA23227 for ; Thu, 14 Oct 2004 01:49: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 i9E5g4se024867; Wed, 13 Oct 2004 22:42:04 -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 i9E5g4LN024866; Wed, 13 Oct 2004 22:42:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E5g2Vu024844 for ; Wed, 13 Oct 2004 22:42:03 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 14 Oct 2004 15:42:34 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Oct 2004 15:42:21 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1FDD0E1A-1D8D-11D9-A16E-003065EA6144@geckotribe.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/10/04 12:59 PM, "Antone Roundy" wrote: > I can conceive of comments, versions, trackbacks, pings and maybe license > being handled quite similarly (on click/select/whatever, display another > newsfeed or a web page), though I'd have to see definitions of them to be sure > they mean what I think they mean. > "comments" would be defined as being "here is a resource of comments on this entry", and it would depend on the mime-type of the resource as to what exactly happens next. If it is "text/html" you know it's a web page, if it is "application/pdf" you can punt the retrieved resource to your PDF viewer plugin/application, if it is "application/atom+xml" you could display the feed of comments in the aggregator itself and even offer to subscribe to that feed. Similarly versions, trackbacks, pings. License would be a link to a resource describing the license for the entry, whether it's a CC license page, or a GNU license page, or whatever. (I can see however that these definitions are not entirely obvious: someone somewhere is likely to interpret "comments" as meaning "here is a service point for submitting comments") > I have no idea what is meant by components, so have no comment on that. While discussing play lists it struck me that some folks might want to provide a list of components for any given mp3, such that others might then take those components and re-mix them. That list could be in any format, not just atom. See the @type attribute to determine. Thus one entry which is discusses "Violin Concerto in D major, Opus 77, Second Movement" could have a link to another atom feed document in which each entry is a different instrument. Also, one entry which is an alternate for a 200 page PDF could have a components link in which each entry is an alternate for each of the chapters of that PDF. Download the whole monolithic thing, or dig a little deeper and retrieve an atom feed document which summarises each chapter and offers links to smaller PDFs. > Prefetch seems ... a little out of place. Not that an element with that > purpose is necessarily a bad idea, but it doesn't fit my mental model of a > Link Construct. By itself it doesn't make a lot of sense. But if you had an @rel with "transcription prefetch" (and @type="application/mpeg") you'd know that the publisher has indicated they don't mind if you prefetch that resource (whether prefetching occurs off peak, or simply initiates immediately on display of the individual entry). In the same class as "prefetch" you could also have other relationship modifiers, like votes [1] or authority qualifiers (like 'factchecked', 'second-sourced', 'rumor' [2]), or a richer set of qualifies such as discussed in the hypertext community [3]. One important note: these are advanced uses of the @rel attribute, which might scare some folks. Remember though that the fall back position is that a user-agent is free to ignore any @rel value it doesn't recognise. e. [1] http://developers.technorati.com/wiki/VoteLinks [2] made up on the spot right now, so usual caveats apply [3] http://www.eastgate.com/HypertextNow/archives/Trigg.html From owner-atom-syntax@mail.imc.org Thu Oct 14 01:53: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 BAA23542 for ; Thu, 14 Oct 2004 01:53: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 i9E5j1aZ026347; Wed, 13 Oct 2004 22:45:01 -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 i9E5j1WK026346; Wed, 13 Oct 2004 22:45:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E5ixZm026328 for ; Wed, 13 Oct 2004 22:45:00 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 14 Oct 2004 15:45:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 14 Oct 2004 15:45:19 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4CEEB034-1D90-11D9-A16E-003065EA6144@geckotribe.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14/10/04 1:22 PM, "Antone Roundy" wrote: > One more thing--there's an argument for not setting the bar too high: > if it is too difficult to get new values officially recognized, we run > the risk of people making up new values without going through the > process. For this reason, it may be best to devise a mechanism that > ensures (as much as possible) that we don't get naming collisions. > What a dilemma. I thought your #5 hit the mark regarding this point. > 5) Bothersome but doable: register a prefix At least this way if people don't bother with registering their prefix then the scope of name clashes is only with prefixes, not the full set of @rel values. e. From owner-atom-syntax@mail.imc.org Thu Oct 14 07:55: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 HAA05880 for ; Thu, 14 Oct 2004 07:55:16 -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 i9EBjBGH070674; Thu, 14 Oct 2004 04:45:11 -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 i9EBjBGh070673; Thu, 14 Oct 2004 04:45:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBjAjJ070589 for ; Thu, 14 Oct 2004 04:45:11 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9EBgC1X002041; Thu, 14 Oct 2004 12:42:17 +0100 (BST) In-Reply-To: <416D552B.3030607@debpro.webcom.dk> References: <416D552B.3030607@debpro.webcom.dk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--812150983; protocol="application/pkcs7-signature" Message-Id: <17226AE6-1DD6-11D9-B4F4-000A2797ECDA@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Date: Thu, 14 Oct 2004 12:42:06 +0100 To: Jacob Larsen X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--812150983 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit No, and I hope it never does, because they're really not useful and don't reflect how sites are published. What skipHours and skipDays do is require you to promise that you never publish anything between certain hours and on certain days, which is a too big a commitment for them to make or me to trust. What would be useful is if a blogger could add a temporary note to their feed saying I'm going to bed now, I can absolutely guarantee nothing will change in the next few hours. Or a site that publishes once a day (but at irregular times) can say here's today update, nothing more for at least 12 hours. Something like that. Graham --Apple-Mail-2--812150983 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE0MTE0MjA4WjAjBgkqhkiG9w0BCQQxFgQUgJs9kLbwBOhBmG29icv6O++0 dg0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAhktK7EURv7dC3BVjvRBv1nom vUORw/tah/Zrx8GdD+3Cri/EYbaWGWkkoi1N2zrMATXAbimkdI11dXfUjTr8aEpGCsooSSQjeGgJ 95BJq8PUoRA9VOdhI1F1C/eSiOzXgoDhiSj4jhTLQ0GnHwEif9khyd2JpcLWqwpPlVlM8rU1Tzm5 qwtvoz7bFzxIof039h+yA4n2XuksdZJJjLiGV/M9LwZoqFK4481/c97FNrjUn/QH43ETNGkCaPyr FkgVkK+9CqguRdeZToIBKwHV9bUlJ3yE0wcw3I1qiRFpzAuOIVG2M7enDu00xxI4yjQ0ab76bUVp voVSbtjvpqqNewAAAAAAAA== --Apple-Mail-2--812150983-- From owner-atom-syntax@mail.imc.org Thu Oct 14 08:22:58 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 IAA08366 for ; Thu, 14 Oct 2004 08:22:58 -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 i9ECFDam074675; Thu, 14 Oct 2004 05:15: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 i9ECFDpT074674; Thu, 14 Oct 2004 05:15: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECFDFw074665 for ; Thu, 14 Oct 2004 05:15:13 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so315798rnk for ; Thu, 14 Oct 2004 05:15:10 -0700 (PDT) Received: by 10.38.8.35 with SMTP id 35mr218352rnh; Thu, 14 Oct 2004 05:15:09 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 14 Oct 2004 05:15:09 -0700 (PDT) Message-ID: <1f2ed5cd0410140515374d0052@mail.gmail.com> Date: Thu, 14 Oct 2004 14:15:09 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: enclosures: types Cc: Atom Syntax In-Reply-To: <416D964F.2040607@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041013094353.GB5713@tartarus.org> <416D4366.2000405@franklinmint.fm> <1f2ed5cd0410131341276f29ad@mail.gmail.com> <416D964F.2040607@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 13 Oct 2004 16:55:43 -0400, Robert Sayre wrote: > > > > >>I think the type attribute is useful metadata in the same sense that the > >>title attribute is. If we omit it, we'll just see stuff like this: > >> > >> > >> > >>That's something we often see in HTML. There's your use case. > > > > > > Well, not really because you can still do a HEAD and it doens't make > > the in-content statement any more reliable. > > Then why does HTML have @type? Because the TAG group arrived late? Lines like this don't exactly inspire confidence: [[ Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address. ]] http://www.w3.org/TR/REC-html40/struct/links.html#adef-type-A btw, HTML 2.0 had URN (c.f. atom:id) and METHODS (c.f. atom:service) - http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.7.3 > > If the type attribute inline will be non-redundant, accurate and > > useful information then let's have it > > Ha! Which part of the Atom format makes that guarantee? This runs along with why I don't think developer patterns are appropriate for specs - the MUSTs in the spec do make guarantees. But their fidelity evaporates when it gets to implementation. Specs are defined for an idealized world, laws put in as compromises are part of the idealization. In this case redundancy and utility can be determined pretty clearly, accuracy is a bit floppy. @type is there > to present alternatives, just like @title. Hmm, it's a grey area but there is something of a qualitative difference in that one is designed primarily for human interpretation and the other machine interpretation. Having the wrong title has little consequence to the application behaviour, the wrong type might well prevent something from working. I really don't know. Perhaps there is justification for @type, but I would think it would have to be optional and qualified with a Postelian MUST for publisher accuracy and MAY for consumer advisory. btw, what are the alternatives presented to @title? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 14 08:43:12 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 IAA09718 for ; Thu, 14 Oct 2004 08:43:12 -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 i9ECZceY077227; Thu, 14 Oct 2004 05:35:38 -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 i9ECZcVe077226; Thu, 14 Oct 2004 05:35:38 -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 i9ECZck6077208 for ; Thu, 14 Oct 2004 05:35:38 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CI4pT-0000Fm-9q; Thu, 14 Oct 2004 12:35:35 +0000 Message-ID: <416E7294.4000608@franklinmint.fm> Date: Thu, 14 Oct 2004 08:35:32 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom Syntax Subject: Re: enclosures: types References: <20041013094353.GB5713@tartarus.org> <416D4366.2000405@franklinmint.fm> <1f2ed5cd0410131341276f29ad@mail.gmail.com> <416D964F.2040607@franklinmint.fm> <1f2ed5cd0410140515374d0052@mail.gmail.com> In-Reply-To: <1f2ed5cd0410140515374d0052@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Wed, 13 Oct 2004 16:55:43 -0400, Robert Sayre wrote: > > > This runs along with why I don't think developer patterns are > appropriate for specs - the MUSTs in the spec do make guarantees. But > their fidelity evaporates when it gets to implementation. Specs are > defined for an idealized world, laws put in as compromises are part of > the idealization. In this case redundancy and utility can be > determined pretty clearly, accuracy is a bit floppy. > No. You'll find plenty of handwaving in lots of good specs. "Advisory media type" is good enough for HTML and it's good enough for me. We're not going to pin this one down. > I really don't know. Perhaps there is justification for @type, but I > would think it would have to be optional and qualified with a > Postelian MUST for publisher accuracy and MAY for consumer advisory. > > btw, what are the alternatives presented to @title? "There you go again" :) This is an issue you can solve with conneg and alternate links. If someone subscribes to a feed with 10 titles for 10 entries that's 100 titles, of which 10 will be viewed. HTTP users call that "slow". Hanging 10 entries off of one URI is bad enough, but the hack breaks once you start hanging huge subtrees of alternates off of those entries. Anyway, this is a bikeshed discussion. I suggest you write a Pace that outlines how clients are to act in the absence of @type. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 14 09:00:59 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 JAA11062 for ; Thu, 14 Oct 2004 09:00:58 -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 i9ECot2Q079359; Thu, 14 Oct 2004 05:50: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 i9ECotSU079358; Thu, 14 Oct 2004 05:50:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECosT5079330 for ; Thu, 14 Oct 2004 05:50:54 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CI54D-0004rA-00; Thu, 14 Oct 2004 13:50:49 +0100 Date: Thu, 14 Oct 2004 13:50:49 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: The like of =?iso-8859-1?Q?RSS?= =?iso-8859-1?Q?=B4?= ttl, skipHours or skipDays Message-ID: <20041014125049.GP10418@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <416D552B.3030607@debpro.webcom.dk> <17226AE6-1DD6-11D9-B4F4-000A2797ECDA@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17226AE6-1DD6-11D9-B4F4-000A2797ECDA@mac.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 14, 2004 at 12:42:06PM +0100, Graham wrote: > No, and I hope it never does, because they're really not useful and > don't reflect how sites are published. What skipHours and skipDays do > is require you to promise that you never publish anything between > certain hours and on certain days, which is a too big a commitment for > them to make or me to trust. Strictly, they require you to not care that users won't pick up new items between certain hours and on certain days. It's a minor distinction, really. I certainly don't think it's functionality we care about for Atom. > What would be useful is if a blogger could add a temporary note to > their feed saying I'm going to bed now, I can absolutely guarantee > nothing will change in the next few hours. Or a site that publishes > once a day (but at irregular times) can say here's today update, > nothing more for at least 12 hours. Something like that. An Expires semantic would solve that, which has been proposed I think. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Thu Oct 14 09:44: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 JAA17382 for ; Thu, 14 Oct 2004 09:44:05 -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 i9EDafeM087836; Thu, 14 Oct 2004 06:36: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 i9EDaff3087835; Thu, 14 Oct 2004 06:36:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9EDaeBL087815 for ; Thu, 14 Oct 2004 06:36:41 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041014133636.20443.qmail@web41207.mail.yahoo.com> Received: from [24.18.132.123] by web41207.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 06:36:36 PDT Date: Thu, 14 Oct 2004 06:36:36 -0700 (PDT) From: Dare Obasanjo Subject: Re: The like of RSSŽ ttl, skipHours or skipDays To: Graham , Jacob Larsen Cc: atom-syntax@imc.org In-Reply-To: <17226AE6-1DD6-11D9-B4F4-000A2797ECDA@mac.com> 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: --- Graham wrote: > No, and I hope it never does, because they're really > not useful and > don't reflect how sites are published. What > skipHours and skipDays do > is require you to promise that you never publish > anything between > certain hours and on certain days, which is a too > big a commitment for > them to make or me to trust. I see those tags as another way for me to get bogus bug reports from users who are wondering why my aggregator didn't pick up posts in certain feeds on particular days. Those elements are a hacky holdover from when the RSS mavens didn't realize HTTP conditional GET requests and GZip encoding existed. > What would be useful is if a blogger could add a > temporary note to > their feed saying I'm going to bed now, I can > absolutely guarantee > nothing will change in the next few hours. Or a site > that publishes > once a day (but at irregular times) can say here's > today update, > nothing more for at least 12 hours. Something like > that. I probably would ignore this as well. I can't imagine many people are going to manage this on a daily or even weekly basis. Who cares about their RSS bandwidth usage enough to micromanage stuff to that extent? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 14 10:03:38 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 KAA19004 for ; Thu, 14 Oct 2004 10:03:37 -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 i9EDr53n091416; Thu, 14 Oct 2004 06:53:05 -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 i9EDr5ud091415; Thu, 14 Oct 2004 06:53:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EDr5kl091402 for ; Thu, 14 Oct 2004 06:53:05 -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 (sccrmhc12) with SMTP id <2004101413530101200fpudue>; Thu, 14 Oct 2004 13:53:02 +0000 Date: Thu, 14 Oct 2004 07:52:56 -0600 Subject: Re: atom:link state of play 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: Message-Id: <5A0D73C4-1DE8-11D9-9250-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, October 13, 2004, at 11:42 PM, Eric Scheid wrote: >> Prefetch seems ... a little out of place. Not that an element with >> that >> purpose is necessarily a bad idea, but it doesn't fit my mental model >> of a >> Link Construct. > > By itself it doesn't make a lot of sense. But if you had an @rel with > "transcription prefetch" (and @type="application/mpeg") you'd know > that the > publisher has indicated they don't mind if you prefetch that resource > (whether prefetching occurs off peak, or simply initiates immediately > on > display of the individual entry). > > In the same class as "prefetch" you could also have other relationship > modifiers, like votes [1] or authority qualifiers (like 'factchecked', > 'second-sourced', 'rumor' [2]), or a richer set of qualifies such as > discussed in the hypertext community [3]. > The thing is, "prefetch", "factchecked"...don't describe the relationship between the entry and the other resource. One is a hint about how to handle the resource, or a note about the FEED publisher's intentions regarding the resource (BTW, a link to an MP3, for example, might not be published by the publisher of the MP3, so whether they mind if it's prefetched or not might not be an appropriate bit of info to communicate), and the others are metadata about the link target, not the relationship between them. This kind of information belongs somewhere other than @atom:rel. "vote-for", "vote-abstain", "vote-againt" would be reasonable @rel values, though I don't think they belong in the core. From owner-atom-syntax@mail.imc.org Thu Oct 14 10:10: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 KAA20518 for ; Thu, 14 Oct 2004 10:10: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 i9EE2Zsh092660; Thu, 14 Oct 2004 07:02:35 -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 i9EE2ZAY092659; Thu, 14 Oct 2004 07:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EE2Y33092650 for ; Thu, 14 Oct 2004 07:02:35 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CI6Bg-0008IU-00; Thu, 14 Oct 2004 15:02:36 +0100 Date: Thu, 14 Oct 2004 15:02:36 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: The like of =?iso-8859-1?Q?RSS?= =?iso-8859-1?Q?=B4?= ttl, skipHours or skipDays Message-ID: <20041014140236.GU10418@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <17226AE6-1DD6-11D9-B4F4-000A2797ECDA@mac.com> <20041014133636.20443.qmail@web41207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041014133636.20443.qmail@web41207.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 14, 2004 at 06:36:36AM -0700, Dare Obasanjo wrote: > > What would be useful is if a blogger could add a temporary > > note to their feed saying I'm going to bed now, I can > > absolutely guarantee nothing will change in the next few hours. > > I probably would ignore this as well. I can't imagine > many people are going to manage this on a daily or > even weekly basis. Who cares about their RSS bandwidth > usage enough to micromanage stuff to that extent? It might be a useful thing to display as well, but it would depend on how the publisher support worked. I suspect it would be of use only in certain edge cases. Plus, it can be handled at the HTTP level (which doesn't work for Bob, but Bob probably isn't an edge case). James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Thu Oct 14 10:29: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 KAA23975 for ; Thu, 14 Oct 2004 10:29: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 i9EELEnP096084; Thu, 14 Oct 2004 07:21:14 -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 i9EELEtf096083; Thu, 14 Oct 2004 07:21:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EELEC1096062 for ; Thu, 14 Oct 2004 07:21:14 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i9EELEYJ014345 for ; Thu, 14 Oct 2004 07:21:14 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i9ECKomo022913 for ; Thu, 14 Oct 2004 07:20:52 -0500 Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id i9EELA5j018254; Thu, 14 Oct 2004 09:21:10 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I5K00C9DVVAJ9@ims1.labs.mot.com>; Thu, 14 Oct 2004 09:21:10 -0500 (CDT) Date: Thu, 14 Oct 2004 09:21:11 -0500 From: Brett Lindsley Subject: Re: The like of =?windows-1252?Q?=3F_ttl=2C_skipHours_or_?= =?windows-1252?Q?skipDays?= To: Dare Obasanjo Cc: Graham , Jacob Larsen , atom-syntax@imc.org Message-id: <416E8B57.8070009@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_eUUElQ9ZVfq/1rYx63jWqA)" X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <20041014133636.20443.qmail@web41207.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary_(ID_eUUElQ9ZVfq/1rYx63jWqA) Content-type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7BIT Dare Obasanjo wrote: >--- Graham wrote: > > > >>No, and I hope it never does, because they're really >>not useful and >>don't reflect how sites are published. What >>skipHours and skipDays do >>is require you to promise that you never publish >>anything between >>certain hours and on certain days, which is a too >>big a commitment for >>them to make or me to trust. >> >> > >I see those tags as another way for me to get bogus >bug reports from users who are wondering why my >aggregator didn't pick up posts in certain feeds on >particular days. > >Those elements are a hacky holdover from when the RSS >mavens didn't realize HTTP conditional GET requests >and GZip encoding existed. > > > >>What would be useful is if a blogger could add a >>temporary note to >>their feed saying I'm going to bed now, I can >>absolutely guarantee >>nothing will change in the next few hours. Or a site >>that publishes >>once a day (but at irregular times) can say here's >>today update, >>nothing more for at least 12 hours. Something like >>that. >> >> > >I probably would ignore this as well. I can't imagine >many people are going to manage this on a daily or >even weekly basis. Who cares about their RSS bandwidth >usage enough to micromanage stuff to that extent? > People with portable devices with limited bandwidth connections may worry about their bandwidth usage. > >===== >THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 >I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. > > > >_______________________________ >Do you Yahoo!? >Declare Yourself - Register online to vote today! >http://vote.yahoo.com > > > --Boundary_(ID_eUUElQ9ZVfq/1rYx63jWqA) Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7BIT

Dare Obasanjo wrote:
--- Graham <dtcd@mac.com> wrote:

  
No, and I hope it never does, because they're really
not useful and 
don't reflect how sites are published. What
skipHours and skipDays do 
is require you to promise that you never publish
anything between 
certain hours and on certain days, which is a too
big a commitment for 
them to make or me to trust.
    

I see those tags as another way for me to get bogus
bug reports from users who are wondering why my
aggregator didn't pick up posts in certain feeds on
particular days. 

Those elements are a hacky holdover from when the RSS
mavens didn't realize HTTP conditional GET requests
and GZip encoding existed. 

  
What would be useful is if a blogger could add a
temporary note to 
their feed saying I'm going to bed now, I can
absolutely guarantee 
nothing will change in the next few hours. Or a site
that publishes 
once a day (but at  irregular times) can say here's
today update, 
nothing more for at least 12 hours. Something like
that.
    

I probably would ignore this as well. I can't imagine
many people are going to manage this on a daily or
even weekly basis. Who cares about their RSS bandwidth
usage enough to micromanage stuff to that extent?

People with portable devices with limited bandwidth connections may worry about
their bandwidth usage.


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

--Boundary_(ID_eUUElQ9ZVfq/1rYx63jWqA)-- From owner-atom-syntax@mail.imc.org Thu Oct 14 10:46: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 KAA25955 for ; Thu, 14 Oct 2004 10:46: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 i9EEdpfH099243; Thu, 14 Oct 2004 07:39:51 -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 i9EEdpLk099242; Thu, 14 Oct 2004 07:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9EEdp3X099225 for ; Thu, 14 Oct 2004 07:39:51 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041014143948.58428.qmail@web41206.mail.yahoo.com> Received: from [24.18.132.123] by web41206.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 07:39:47 PDT Date: Thu, 14 Oct 2004 07:39:47 -0700 (PDT) From: Dare Obasanjo Subject: Re: The like of ? ttl, skipHours or skipDays To: Brett Lindsley Cc: Graham , Jacob Larsen , atom-syntax@imc.org In-Reply-To: <416E8B57.8070009@labs.mot.com> 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: --- Brett Lindsley wrote: > > People with portable devices with limited bandwidth > connections may > worry about > their bandwidth usage. There are people serving RSS feeds from their portable device? This is news to me. If you are serving a blog and an RSS feed from your portable device you have MUCH BIGGER bandwidth issues than skip* and ttl can solve. :) ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 14 12:31: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 MAA05167 for ; Thu, 14 Oct 2004 12:31:41 -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 i9EGHrOi013853; Thu, 14 Oct 2004 09:17: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 i9EGHr87013852; Thu, 14 Oct 2004 09:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EGHqSV013834 for ; Thu, 14 Oct 2004 09:17:52 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA02085 for ; Thu, 14 Oct 2004 09:17:48 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA11770 for ; Thu, 14 Oct 2004 09:17:48 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 14 Oct 2004 09:17:47 -0700 Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9EGGlhc028206 for ; Thu, 14 Oct 2004 09:16:47 -0700 (PDT) Date: Thu, 14 Oct 2004 09:20:46 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Message-ID: <3F92DD85B416235128865DBB@diva.verity.com> In-Reply-To: <20041014133636.20443.qmail@web41207.mail.yahoo.com> References: <20041014133636.20443.qmail@web41207.mail.yahoo.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Thursday, October 14, 2004 06:36:36 AM -0700 Dare Obasanjo wrote: > > I probably would ignore this [Expires] as well. I can't imagine > many people are going to manage this on a daily or > even weekly basis. Who cares about their RSS bandwidth > usage enough to micromanage stuff to that extent? A site that publishes press releases after the market close. They can reliably say that the feed doesn't expire until the next market close. Plenty of sites have strict publishing schedules and some of them are high volume. The real advantage is also putting the date in HTTP headers so that HTTP caches can handle conditional GETs from aggregators. Whether they ignore Expires or are fetching the feed for the first time, the cache can take the load. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Thu Oct 14 12:47: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 MAA06437 for ; Thu, 14 Oct 2004 12:47: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 i9EGeJA5017010; Thu, 14 Oct 2004 09:40: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 i9EGeJ1G017009; Thu, 14 Oct 2004 09:40:19 -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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EGeIs6017001 for ; Thu, 14 Oct 2004 09:40:18 -0700 (PDT) (envelope-from lavandowska@gmail.com) Received: by mproxy.gmail.com with SMTP id 78so174458rnl for ; Thu, 14 Oct 2004 09:40:18 -0700 (PDT) Received: by 10.38.79.70 with SMTP id c70mr217290rnb; Thu, 14 Oct 2004 09:40:18 -0700 (PDT) Received: by 10.38.83.65 with HTTP; Thu, 14 Oct 2004 09:40:18 -0700 (PDT) Message-ID: <96d7d77c04101409404cca99c2@mail.gmail.com> Date: Thu, 14 Oct 2004 11:40:18 -0500 From: Lance Lavandowska Reply-To: Lance Lavandowska To: Atom Syntax Subject: Re: atom:link state of play In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If anyone is interested in the opinions of a rather 'naive observer'[1] see comments/votes inline: On Wed, 13 Oct 2004 17:35:24 -0700, Tim Bray wrote: > The following Paces are clinging to life, have a single -1 but aren't > being strung up to the rafters by a howling mob: > > PaceLinkConstruct (adds rev="comment|update|replaces") -0 > PaceLinkDelicious (add "related" and "about" to @rel values) > PaceLinkParent (add "in-reply-to" to @rel values) +1 to these two > PaceReplaceLinkElement (no @rel, , , > , etc...) A guarded +1, concerned this could go too far. > There's a PaceServiceElement out there that takes the service.this and > service.that out of the repertoire of @rel and adds type=""> or some such, and it's got enough +1's that I was convinced it > had already been accepted, but I guess not. But I bet it will be, so > it might be reasonable to omit the service.* values in discussion of I also thought this was accepted: +1 > The following mechanisms are on the table for an extensible link > construct: > > 1. @rel values from keyword list hardwired in the spec (current draft) > 2. @rel values have prefixes from an IANA registry > (PaceLinkRelPrefixReg) > 3. @rel values are qnames (PaceLinkRelMechanism) > 4. @rel values are URIs (PaceLinkRelUri) > 5. anything with an atom:href attribute is a link > (PaceRelationshipConstruct) > 6. a general construct-signaling mechanism (PaceConstructAttribute). > [Steve Newcomb, where are you? This idea is at least 15 years old, > it's called "Architectural Forms" and is an ISO Standard, see Annex A > of ISO 10744] > 7. Invent a new element for each type of link (PaceReplaceLinkElement) Half of these I just don't understand (I don't have *that* much time for reading all the background info) and the other half seem like quibbling over semantics to me. #7 scares me a bit with the potential for element explosion. I'm tending to side with allowing anything in there, let the clients sort it out (ignore what they don't understand or make it a link, whatever). Then see what real-life usage looks like. Waffle. Lance [1] definition of 'naive observer': I haven't written an aggregator or client of any sort. I've "implemented" a feed generator through copy-paste, though I read the spec first. I wrote a pre-alpha implementation of the atom-api in Java (last year). I try to keep up with the discussions on this list but often fail. I don't have the time to read every Pace nor any of the backing theory/RFCs. From owner-atom-syntax@mail.imc.org Thu Oct 14 13:16:26 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 NAA08818 for ; Thu, 14 Oct 2004 13:16:26 -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 i9EH6SlT021604; Thu, 14 Oct 2004 10:06: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 i9EH6SxQ021603; Thu, 14 Oct 2004 10:06:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EH6Qwm021576 for ; Thu, 14 Oct 2004 10:06:27 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9EH2Crk015912; Thu, 14 Oct 2004 18:02:12 +0100 (BST) In-Reply-To: <20041014133636.20443.qmail@web41207.mail.yahoo.com> References: <20041014133636.20443.qmail@web41207.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--792951734; protocol="application/pkcs7-signature" Message-Id: Cc: Jacob Larsen , atom-syntax@imc.org From: Graham Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Date: Thu, 14 Oct 2004 18:02:11 +0100 To: Dare Obasanjo X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--792951734 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 14 Oct 2004, at 2:36 pm, Dare Obasanjo wrote: > I probably would ignore this as well. I can't imagine > many people are going to manage this on a daily or > even weekly basis. Who cares about their RSS bandwidth > usage enough to micromanage stuff to that extent? Well yes. It's the nearest thing to a useful way of doing it that I can think of, so I guess we all agree trying to predict the future is a waste of time? Graham --Apple-Mail-2--792951734 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE0MTcwMjEyWjAjBgkqhkiG9w0BCQQxFgQU3mFblfwMf0MbxuMnUaWMRZ0I VmkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAbGAcXqnmXVf5uiOTc8qrnh+/ f4OOosJUMTnYz8bocfCDouQgOTQI3aq0+lNHxI+mrfQEpbBDjJh5f/2n8Q1XAnRVaekhWUSed3yv LxeYXQSZFqnXLZzj0y4DOYqsjYSCh7DSq0dL5ym0Nht8d2McTPkMLw8WaSqepHZGanWfIwNZmi7Q zWNUpp4JysLcZRfyqusMOFBnn0pEUOmUgt+266n2mYWQZBFv5QjfPZXhUhVg4uVXhLeDR3LGIgcG M3CuXPI6ZPLZuS3A0rljC/HW+Q4guJn++GdUfe220scfulu5EOtHmyMtlWuhaJMs7we8PoDVRLCT A71iVOS9CFyUigAAAAAAAA== --Apple-Mail-2--792951734-- From owner-atom-syntax@mail.imc.org Thu Oct 14 13:40:28 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 NAA10635 for ; Thu, 14 Oct 2004 13:40:27 -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 i9EHUTrJ025784; Thu, 14 Oct 2004 10:30:29 -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 i9EHUTvb025783; Thu, 14 Oct 2004 10:30:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EHUS9R025765 for ; Thu, 14 Oct 2004 10:30:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9EHRGir025635; Thu, 14 Oct 2004 18:27:16 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--791447525; protocol="application/pkcs7-signature" Message-Id: <4B5B61C4-1E06-11D9-9D68-000A2797ECDA@mac.com> Cc: Atom Syntax From: Graham Subject: Re: atom:link state of play Date: Thu, 14 Oct 2004 18:27:16 +0100 To: Tim Bray X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3--791447525 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 14 Oct 2004, at 1:35 am, Tim Bray wrote: > PaceReplaceLinkElement (no @rel, Pardon? That's the point of it. > , , , etc...) Well that's because they were missing from the most comprehensive list I could find at the time. Graham > The only defined value for @rel on atom:link would be "alternate" and > that would be the default I propose that "alternate" is a very special case and shouldn't be mixed in with other types of link, which ever proposals we adopt. Graham --Apple-Mail-3--791447525 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE0MTcyNzE2WjAjBgkqhkiG9w0BCQQxFgQU8g6FyY5XVHv2xFEVTla8xbex fGYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAEdb6cUK252y18YkCK3YQCQ7F dQdpo+LoW2zn68UiMlSpH3Fukz3kC42KBFt/jjDZGyOnt/LtU5+fBP8u8wlJaOlpAVfFtdVy90Yy DJ+LFuoC/9dfXvAuhWkDvNkGZUvow0TQbAAjRAC4rchVf5DHxD8W3sC+heWGFio2HbcovB9crH4n /JSM/6ZOElK9m6B4hDopdpN1pxecgpEU8j53v1C0bYpub0/nrkis3DpRHRaUmxCOpEp5CKVkE9vL oUOLhVn029zKtulsFdi4noOCRfKpE+pBzZJ+HbnGD7+GBfl1Fy4tJIlNvY2VFHuZY9BQfK83rxug 4X/20Yrobnwt3AAAAAAAAA== --Apple-Mail-3--791447525-- From owner-atom-syntax@mail.imc.org Thu Oct 14 13:40: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 NAA10671 for ; Thu, 14 Oct 2004 13:40: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 i9EHU6Ie025718; Thu, 14 Oct 2004 10:30: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 i9EHU6r2025717; Thu, 14 Oct 2004 10:30:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EHU5hN025696; Thu, 14 Oct 2004 10:30:05 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9EHU9ui027025; Thu, 14 Oct 2004 11:30:09 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5L0040W4M8DG@edgemail1.Central.Sun.COM>; Thu, 14 Oct 2004 11:30:08 -0600 (MDT) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5L00KUZ4M73K@mail.sun.net>; Thu, 14 Oct 2004 11:30:08 -0600 (MDT) Date: Thu, 14 Oct 2004 10:30:28 -0700 From: Tim Bray Subject: Re: atom:link state of play In-reply-to: To: Paul Hoffman / IMC Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 13, 2004, at 7:49 PM, Paul Hoffman / IMC wrote: > Would you (and others) be happy with a simple IANA registry that gets > filled in when there is a standards-track RFC. It would start with > "alternate -> RFC {ournumber}", and entries would be added as the RFCs > issued. FWIW, it would be perfectly permissible for a single RFC to be > the registration for multiple new values. I could go for this, only the registry should have more than one initial value. I would ruthlessly refuse any "would-be-nice" values and accept only things that have been very widely deployed and used already . Specifically: "alternate", "about", and "attachment". And if we *can't* get consensus on this list, I say the hell with it, just have an with no @rel, used for what we now call rel='alternate', and leave the rest for extensions. -Tim From owner-atom-syntax@mail.imc.org Thu Oct 14 13:41: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 NAA10779 for ; Thu, 14 Oct 2004 13:41:45 -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 i9EHWSjh026145; Thu, 14 Oct 2004 10:32: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 i9EHWS7u026144; Thu, 14 Oct 2004 10:32:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EHWRVU026124 for ; Thu, 14 Oct 2004 10:32:27 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id KAA07595 for ; Thu, 14 Oct 2004 10:32:25 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id KAA21142 for ; Thu, 14 Oct 2004 10:32:25 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 14 Oct 2004 10:32:25 -0700 Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9EHVOhc028496 for ; Thu, 14 Oct 2004 10:31:24 -0700 (PDT) Date: Thu, 14 Oct 2004 10:35:24 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Message-ID: In-Reply-To: References: <20041014133636.20443.qmail@web41207.mail.yahoo.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Thursday, October 14, 2004 06:02:11 PM +0100 Graham wrote: > > Well yes. It's the nearest thing to a useful way of doing it that I can think > of, so I guess we all agree trying to predict the future is a waste of time? Making predictions is hard, but very useful. The caching folk have already figured this out, all we need to do is follow their lead. Some publishers *know* the future schedule, and that knowledge is much better than a prediction. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Thu Oct 14 14:25:07 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 OAA13366 for ; Thu, 14 Oct 2004 14:25: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 i9EIHIKn032411; Thu, 14 Oct 2004 11:17: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 i9EIHIa5032410; Thu, 14 Oct 2004 11:17:18 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EIHENx032394; Thu, 14 Oct 2004 11:17:15 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 14 Oct 2004 11:17:16 -0700 To: Tim Bray From: Paul Hoffman / IMC Subject: Re: atom:link state of play 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:30 AM -0700 10/14/04, Tim Bray wrote: >I could go for this, only the registry should have more than one >initial value. I would ruthlessly refuse any "would-be-nice" values >and accept only things that have been very widely deployed and used >already . > >Specifically: "alternate", "about", and "attachment". Those three work for me. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Oct 14 14:26: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 OAA13417 for ; Thu, 14 Oct 2004 14:26: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 i9EIFOnf032208; Thu, 14 Oct 2004 11:15: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 i9EIFOxp032207; Thu, 14 Oct 2004 11:15:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EIFNx1032190 for ; Thu, 14 Oct 2004 11:15:23 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id LAA09773 for ; Thu, 14 Oct 2004 11:15:22 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id LAA25611 for ; Thu, 14 Oct 2004 11:15:22 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 14 Oct 2004 11:15:22 -0700 Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9EIELhc028682 for ; Thu, 14 Oct 2004 11:14:21 -0700 (PDT) Date: Thu, 14 Oct 2004 11:18:21 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: PaceReformedContent3 Message-ID: <29DA8AD192960C7D78ECD9E6@diva.verity.com> In-Reply-To: <20041009035024.36523.qmail@web41209.mail.yahoo.com> References: <20041009035024.36523.qmail@web41209.mail.yahoo.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Friday, October 08, 2004 08:50:24 PM -0700 Dare Obasanjo wrote: > --- Eric Scheid wrote: >> >> deaf people often prefer visual communication by >> signing over reading text. > > So a deaf person would rather have someone describe my > blog postings to him as sign language than read it? > That doesn't sound right at all. Sorry for the late response on this one. ASL (American Sign Language) is a different language than English. Different grammar, different vocabulary. If you grew up learning ASL with your (deaf) parents, English may be a second language. An ASL version of an English posting is a translation, not a transcription. This is exactly the same as preferring the posting in your native Spanish instead of your second-language English. Also, "sign language" is a generic term for many different languages, ASL, British Sign Language, French Sign Language, and so on. Last I heard, the ISO language codes incorrectly lump them all under "sgn". The latest info on that seems to be here: http://www.evertype.com/standards/iso639/sgn.html ASL is a really neat language. Learn it if you get the chance. It is quite different from English. For example, you can maintain many more pronouns by choosing spatial locations for concepts. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Thu Oct 14 14:43: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 OAA14548 for ; Thu, 14 Oct 2004 14:43:54 -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 i9EIb75T035717; Thu, 14 Oct 2004 11:37:07 -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 i9EIb7pw035716; Thu, 14 Oct 2004 11:37:07 -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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EIb6uZ035708 for ; Thu, 14 Oct 2004 11:37:07 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so337785rnl for ; Thu, 14 Oct 2004 11:37:08 -0700 (PDT) Received: by 10.38.8.13 with SMTP id 13mr224797rnh; Thu, 14 Oct 2004 11:37:08 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 14 Oct 2004 11:37:08 -0700 (PDT) Message-ID: <1f2ed5cd041014113729d69a50@mail.gmail.com> Date: Thu, 14 Oct 2004 20:37:08 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Walter Underwood Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041014133636.20443.qmail@web41207.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit So would it be fair to summarise: 1. Feed schedule information in RSS 1.0 and 2.0 is/was generally ignored and/or useless. 2. Most publishers and consumers will not see any benefit from scheduling information provided in-document 3. High volume publishers/consumers can gain from the inclusion of scheduling information (cases like PubSub <=> Bloglines) 4. Virtually all the requirements for publishing information can be delivered by the use of an element If so, I'd say this points to including an optional element in the spec. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 14 15:07:48 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 PAA16571 for ; Thu, 14 Oct 2004 15:07:47 -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 i9EIul21038254; Thu, 14 Oct 2004 11:56:47 -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 i9EIuldV038253; Thu, 14 Oct 2004 11:56:47 -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 i9EIulN1038221 for ; Thu, 14 Oct 2004 11:56:47 -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 <20041014185641016000lu3qe>; Thu, 14 Oct 2004 18:56:41 +0000 Date: Thu, 14 Oct 2004 12:56:40 -0600 Subject: Re: atom:link state of play 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: Message-Id: 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 Thursday, October 14, 2004, at 11:30 AM, Tim Bray wrote: > On Oct 13, 2004, at 7:49 PM, Paul Hoffman / IMC wrote: >> Would you (and others) be happy with a simple IANA registry that gets >> filled in when there is a standards-track RFC. It would start with >> "alternate -> RFC {ournumber}", and entries would be added as the >> RFCs issued. FWIW, it would be perfectly permissible for a single RFC >> to be the registration for multiple new values. > > I could go for this, only the registry should have more than one > initial value. I would ruthlessly refuse any "would-be-nice" values > and accept only things that have been very widely deployed and used > already . > > Specifically: "alternate", "about", and "attachment". > > And if we *can't* get consensus on this list, I say the hell with it, > just have an with no @rel, used for what we now call > rel='alternate', and leave the rest for extensions. -Tim I'm about ready to admit defeat on reaching any consensus, and just go write an extension. If we can't reach a consensus that includes useful extensibility without requiring giving up a limb or first child, let's just put something REALLY basic in the core so that it won't end up getting duplicated by extensions. For me, it's either consensus on something extensible or with no @rel. From owner-atom-syntax@mail.imc.org Thu Oct 14 15:10: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 PAA16861 for ; Thu, 14 Oct 2004 15:10: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 i9EIxExF038540; Thu, 14 Oct 2004 11:59:14 -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 i9EIxEar038539; Thu, 14 Oct 2004 11:59:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from beta.verity.com (beta.verity.com [192.187.143.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EIxEvk038515 for ; Thu, 14 Oct 2004 11:59:14 -0700 (PDT) (envelope-from wunder@verity.com) Received: from mx-rr.verity.com ([10.3.100.59]) by beta.verity.com (8.9.3/8.9.3) with ESMTP id LAA11724 for ; Thu, 14 Oct 2004 11:59:13 -0700 (PDT) Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59]) by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id LAA29754 for ; Thu, 14 Oct 2004 11:59:12 -0700 (PDT) Received: from soda.verity.com (soda.verity.com [10.3.100.96]) by mx-rr.verity.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Thu, 14 Oct 2004 11:59:12 -0700 Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9EIw8hc028850 for ; Thu, 14 Oct 2004 11:58:12 -0700 (PDT) Date: Thu, 14 Oct 2004 12:02:08 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: =?ISO-8859-1?Q?Re:_The_like_of_RSS=B4_ttl,_skipHours_or_skipDays?= Message-ID: <830233A4F9412FEC803E337A@diva.verity.com> In-Reply-To: <1f2ed5cd041014113729d69a50@mail.gmail.com> References: <20041014133636.20443.qmail@web41207.mail.yahoo.com> <1f2ed5cd041014113729d69a50@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes. Except for ... --On Thursday, October 14, 2004 08:37:08 PM +0200 Danny Ayers wrote: > So would it be fair to summarise: > > 1. Feed schedule information in RSS 1.0 and 2.0 is/was generally > ignored and/or useless. > > 2. Most publishers and consumers will not see any benefit from > scheduling information provided in-document Most consumers will see a benefit from caching hints, because most consumers will subscribe to at least one high-volume feed. Most publishers will see a small benefit. > 3. High volume publishers/consumers can gain from the inclusion of > scheduling information (cases like PubSub <=> Bloglines) > > 4. Virtually all the requirements for publishing information can be > delivered by the use of an element > > If so, I'd say this points to including an optional element > in the spec. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Thu Oct 14 15:31:42 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 PAA18953 for ; Thu, 14 Oct 2004 15:31:41 -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 i9EJOUqI042357; Thu, 14 Oct 2004 12:24:30 -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 i9EJOUrD042356; Thu, 14 Oct 2004 12:24:30 -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 i9EJOT1p042345 for ; Thu, 14 Oct 2004 12:24:29 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] ([66.57.27.65]) (authenticated bits=0) by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i9EJPB12004609; Thu, 14 Oct 2004 15:25:12 -0400 Message-ID: <416ED26D.2080605@intertwingly.net> Date: Thu, 14 Oct 2004 15:24:29 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: atom:link state of play References: 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 Tim Bray wrote: > > On Oct 13, 2004, at 7:49 PM, Paul Hoffman / IMC wrote: > >> Would you (and others) be happy with a simple IANA registry that gets >> filled in when there is a standards-track RFC. It would start with >> "alternate -> RFC {ournumber}", and entries would be added as the RFCs >> issued. FWIW, it would be perfectly permissible for a single RFC to be >> the registration for multiple new values. > > I could go for this, only the registry should have more than one initial > value. I would ruthlessly refuse any "would-be-nice" values and accept > only things that have been very widely deployed and used already . > > Specifically: "alternate", "about", and "attachment". I'm not sure where these came from. Who has deployed "about"? "attachment"? The following values, as described in http://www.xml.com/lpt/a/2004/06/16/dive.html, have been deployed: "alternate", "related", "via", and "comments". - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 14 15:51:36 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 PAA22224 for ; Thu, 14 Oct 2004 15:51: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 i9EJd8gM044055; Thu, 14 Oct 2004 12:39: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 i9EJd8m4044054; Thu, 14 Oct 2004 12:39:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EJd7OP044047 for ; Thu, 14 Oct 2004 12:39:07 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9EJdBui011838 for ; Thu, 14 Oct 2004 13:39:11 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5L00IYCALBHY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 14 Oct 2004 13:39:11 -0600 (MDT) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5L00L0ZALANG@mail.sun.net> for atom-syntax@imc.org; Thu, 14 Oct 2004 13:39:11 -0600 (MDT) Date: Thu, 14 Oct 2004 12:39:31 -0700 From: Tim Bray Subject: Re: atom:link state of play In-reply-to: <416ED26D.2080605@intertwingly.net> To: Sam Ruby Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <416ED26D.2080605@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 14, 2004, at 12:24 PM, Sam Ruby wrote: > I'm not sure where these came from. Who has deployed "about"? > "attachment"? The deployment of "about" is in some part an artifact of the fuzziness of the definition of in RSS, and to this day I encounter feed items which, when I click on them, I get sent to whatever they're talking about. I do claim it's a widely-deployed semantic. Attachment was a thinko for "enclosure". Which is going through a bit of a vogue right now. > "alternate", "related", "via", and "comments". "related" is more or less "about"? I've never used software that actually did anything intelligent with "via" or "comments" links, but if people generally agree with Sam that they're actually in use out there, that's fine with me. -Tim From owner-atom-syntax@mail.imc.org Thu Oct 14 16:11: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 QAA24475 for ; Thu, 14 Oct 2004 16:10:59 -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 i9EK0DPT046640; Thu, 14 Oct 2004 13:00: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 i9EK0D23046639; Thu, 14 Oct 2004 13:00:13 -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 i9EK0DFq046629 for ; Thu, 14 Oct 2004 13:00:13 -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 <20041014200012014004nb4ge>; Thu, 14 Oct 2004 20:00:12 +0000 Date: Thu, 14 Oct 2004 14:00:10 -0600 Subject: Re: atom:link state of play 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: Message-Id: 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 Thursday, October 14, 2004, at 01:39 PM, Tim Bray wrote: > On Oct 14, 2004, at 12:24 PM, Sam Ruby wrote: >> I'm not sure where these came from. Who has deployed "about"? >> "attachment"? > > The deployment of "about" is in some part an artifact of the fuzziness > of the definition of in RSS, and to this day I encounter feed > items which, when I click on them, I get sent to whatever they're > talking about. I do claim it's a widely-deployed semantic. Ah, good clarification, and certainly true. > Attachment was a thinko for "enclosure". Which is going through a bit > of a vogue right now. I'll put in one last "I don't think this QUITE fits in ", and then claim that from where the sun now stands, I will fight no more forever.[1] ...but reserve the right to speak with a forked tongue. >> "alternate", "related", "via", and "comments". > > "related" is more or less "about"? Similar but subtlely different. about: "I found an article on such and such site, and here are my comments about it." related: "If you want to read further on the topic, here are a few links you might find useful." [1] Chief Joseph From owner-atom-syntax@mail.imc.org Thu Oct 14 16:11:04 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 QAA24507 for ; Thu, 14 Oct 2004 16:11: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 i9EK31IJ047033; Thu, 14 Oct 2004 13:03:01 -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 i9EK31cJ047032; Thu, 14 Oct 2004 13:03:01 -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 i9EK30Gm047025 for ; Thu, 14 Oct 2004 13:03:00 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i9EK3fX3006492; Thu, 14 Oct 2004 16:03:45 -0400 Message-ID: <416EDB73.1080804@intertwingly.net> Date: Thu, 14 Oct 2004 16:02:59 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: atom:link state of play References: <416ED26D.2080605@intertwingly.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 Tim Bray wrote: > On Oct 14, 2004, at 12:24 PM, Sam Ruby wrote: > >> I'm not sure where these came from. Who has deployed "about"? >> "attachment"? > > The deployment of "about" is in some part an artifact of the fuzziness > of the definition of in RSS, and to this day I encounter feed > items which, when I click on them, I get sent to whatever they're > talking about. I do claim it's a widely-deployed semantic. > > Attachment was a thinko for "enclosure". Which is going through a bit > of a vogue right now. > >> "alternate", "related", "via", and "comments". > > "related" is more or less "about"? I've seen a description of "related", but I haven't seen a description of "about". ;-) I agree that "related" is a widely-deployed semantic. Despite being "in vogue", is there any meaningful sense in which other web resources are "attached" or "enclosed"? I can certainly see how audio and mpeg versions of an entry could be the content, or the alternate, or simply be related. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 14 16:27: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 QAA26495 for ; Thu, 14 Oct 2004 16:27:46 -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 i9EKKreL049202; Thu, 14 Oct 2004 13:20: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 i9EKKrgN049201; Thu, 14 Oct 2004 13:20:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKKqle049194 for ; Thu, 14 Oct 2004 13:20:52 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9EKKuui004480 for ; Thu, 14 Oct 2004 14:20:56 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5L00G7CCIWYY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 14 Oct 2004 14:20:56 -0600 (MDT) Received: from [10.0.1.249] ([207.232.126.156]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5L00184CIVSV@mail.sun.net> for atom-syntax@imc.org; Thu, 14 Oct 2004 14:20:56 -0600 (MDT) Date: Thu, 14 Oct 2004 13:21:20 -0700 From: Tim Bray Subject: Re: atom:link state of play In-reply-to: <416EDB73.1080804@intertwingly.net> To: Sam Ruby Cc: Atom Syntax Message-id: <9C1AC85A-1E1E-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 14, 2004, at 1:02 PM, Sam Ruby wrote: > Despite being "in vogue", is there any meaningful sense in which other > web resources are "attached" or "enclosed"? I can certainly see how > audio and mpeg versions of an entry could be the content, or the > alternate, or simply be related. I agree that "attached" and "enclosed" aren't great names. The real semantic is "here is a Web resource, typically large, which the publisher predicts that the user may well want to have a look at and we're putting the URI here outside the content to make it easy for clients to find." On the face of it, the existence of this would seem to make podcasting relatively easier and more straightforward than overloading on rel="related". Suggestions for a better name are welcome. -Tim From owner-atom-syntax@mail.imc.org Thu Oct 14 16:30: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 QAA26796 for ; Thu, 14 Oct 2004 16:30: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 i9EKNiqP049549; Thu, 14 Oct 2004 13:23: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 i9EKNiwG049548; Thu, 14 Oct 2004 13:23:44 -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 i9EKNhfq049541 for ; Thu, 14 Oct 2004 13:23:43 -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 1CIC8T-0006Gh-2Y; Thu, 14 Oct 2004 20:23:41 +0000 Message-ID: <416EE048.5010202@franklinmint.fm> Date: Thu, 14 Oct 2004 16:23:36 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Tim Bray , Atom Syntax Subject: Re: atom:link state of play References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> In-Reply-To: <416EDB73.1080804@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've seen a description of "related", but I haven't seen a description > of "about". ;-) > > I agree that "related" is a widely-deployed semantic. You'll find a description of "about" in PaceLinkDelicious. When I wrote that, it was my underhanded way of proposing content @src. If we have content @src, we don't need it. I think it would be totally cool if we renamed to something like , but it's not a big deal. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 14 16:42: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 QAA28821 for ; Thu, 14 Oct 2004 16:42: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 i9EKWjLj050777; Thu, 14 Oct 2004 13:32:45 -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 i9EKWj9a050776; Thu, 14 Oct 2004 13:32:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKWdvu050751 for ; Thu, 14 Oct 2004 13:32:40 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9EKWgNH014952 for ; Thu, 14 Oct 2004 14:32:42 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5L00G3CD2HYY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 14 Oct 2004 14:32:42 -0600 (MDT) Received: from [10.0.1.249] ([207.232.126.156]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5L001ASD2HSV@mail.sun.net> for atom-syntax@imc.org; Thu, 14 Oct 2004 14:32:41 -0600 (MDT) Date: Thu, 14 Oct 2004 13:33:05 -0700 From: Tim Bray Subject: Re: atom:link state of play In-reply-to: <416EE048.5010202@franklinmint.fm> To: mint@franklinmint.fm Cc: Atom Syntax , Sam Ruby Message-id: <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <416EE048.5010202@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 14, 2004, at 1:23 PM, Robert Sayre wrote: > If we have content @src, we don't need it. I think it would be totally > cool if we renamed to something like , but it's not a > big deal. D'oh, of course. Given content @src, drop attachment/enclosure/whatever That would leave us with alternate|related for sure, and Sam claims that "via" and "comments" are significantly deployed, other voices pro or contra? -Tim From owner-atom-syntax@mail.imc.org Thu Oct 14 16:45:38 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 QAA29642 for ; Thu, 14 Oct 2004 16:45:37 -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 i9EKaicA051285; Thu, 14 Oct 2004 13:36: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 i9EKaiQX051284; Thu, 14 Oct 2004 13:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKahac051269 for ; Thu, 14 Oct 2004 13:36:43 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 6E69448730; Thu, 14 Oct 2004 16:36:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9EKaSG28088; Thu, 14 Oct 2004 16:36:28 -0400 (EDT) Date: Thu, 14 Oct 2004 16:36:28 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Tim Bray Cc: Sam Ruby , Atom Syntax Subject: Re: atom:link state of play In-Reply-To: <9C1AC85A-1E1E-11D9-A19B-000A95A51C9E@sun.com> Message-ID: References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <9C1AC85A-1E1E-11D9-A19B-000A95A51C9E@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 14 Oct 2004, Tim Bray wrote: > On Oct 14, 2004, at 1:02 PM, Sam Ruby wrote: > >> Despite being "in vogue", is there any meaningful sense in which other web >> resources are "attached" or "enclosed"? I can certainly see how audio and >> mpeg versions of an entry could be the content, or the alternate, or simply >> be related. > > I agree that "attached" and "enclosed" aren't great names. The real semantic > is "here is a Web resource, typically large, which the publisher predicts > that the user may well want to have a look at and we're putting the URI here > outside the content to make it easy for clients to find." On the face of it, > the existence of this would seem to make podcasting relatively easier and > more straightforward than overloading on rel="related". Suggestions for a > better name are welcome. -Tim "prefetch" is an obvious candidate. The downside is that it doesn't encompass all the uses supplied for the RSS 2.0 tag. - Lucas From owner-atom-syntax@mail.imc.org Thu Oct 14 16:55: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 QAA01310 for ; Thu, 14 Oct 2004 16:55:05 -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 i9EKmFvq052680; Thu, 14 Oct 2004 13:48: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 i9EKmFlR052679; Thu, 14 Oct 2004 13:48:15 -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 i9EKmETg052673 for ; Thu, 14 Oct 2004 13:48:14 -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 1CICWD-0007X9-F5; Thu, 14 Oct 2004 20:48:13 +0000 Message-ID: <416EE60B.80206@franklinmint.fm> Date: Thu, 14 Oct 2004 16:48:11 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lucas@gonze.com CC: Tim Bray , Sam Ruby , Atom Syntax Subject: Re: atom:link state of play References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <9C1AC85A-1E1E-11D9-A19B-000A95A51C9E@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Lucas Gonze wrote: > > "prefetch" is an obvious candidate. The downside is that it doesn't > encompass all the uses supplied for the RSS 2.0 tag. > I'm confused. This is precisely the problem with that RSS2 tag. "The RSS enclosure element and the Dangers of Overspecification" http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af If you want to download something in the middle of the night, that's fine... I don't see why we should write it into the spec. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 14 17:35:07 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 RAA09038 for ; Thu, 14 Oct 2004 17:35: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 i9ELR8K5057924; Thu, 14 Oct 2004 14:27: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 i9ELR8gq057922; Thu, 14 Oct 2004 14:27:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ELR6lS057914 for ; Thu, 14 Oct 2004 14:27:07 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 400DD4885C; Thu, 14 Oct 2004 17:27:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9ELRB612278; Thu, 14 Oct 2004 17:27:11 -0400 (EDT) Date: Thu, 14 Oct 2004 17:27:11 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: Robert Sayre Cc: lucas@gonze.com, Tim Bray , Sam Ruby , Atom Syntax Subject: Re: atom:link state of play In-Reply-To: <416EE60B.80206@franklinmint.fm> Message-ID: References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <9C1AC85A-1E1E-11D9-A19B-000A95A51C9E@sun.com> <416EE60B.80206@franklinmint.fm> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 14 Oct 2004, Robert Sayre wrote: > Lucas Gonze wrote: >> >> "prefetch" is an obvious candidate. The downside is that it doesn't >> encompass all the uses supplied for the RSS 2.0 tag. >> > I'm confused. This is precisely the problem with that RSS2 tag. > > If you want to download something in the middle of the night, that's fine... > I don't see why we should write it into the spec. I don't know yet what I think about it, because I can't figure out why the original enclosure tag accomplished anything at all. - Lucas From owner-atom-syntax@mail.imc.org Thu Oct 14 17:48:11 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 RAA10244 for ; Thu, 14 Oct 2004 17:48:10 -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 i9ELfMTv060667; Thu, 14 Oct 2004 14:41:22 -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 i9ELfMQh060666; Thu, 14 Oct 2004 14:41:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9ELfLfv060649 for ; Thu, 14 Oct 2004 14:41:21 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041014214121.34793.qmail@web41210.mail.yahoo.com> Received: from [131.107.71.227] by web41210.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 14:41:21 PDT Date: Thu, 14 Oct 2004 14:41:21 -0700 (PDT) From: Dare Obasanjo Subject: Re: atom:link state of play To: Tim Bray , mint@franklinmint.fm Cc: Atom Syntax , Sam Ruby In-Reply-To: <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> 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: --- Tim Bray wrote: > > D'oh, of course. Given content @src, drop > attachment/enclosure/whatever > > That would leave us with alternate|related for sure, > and Sam claims > that "via" and "comments" are significantly > deployed, other voices pro > or contra? If this is the case I'd like this claim backed up with the number of feeds and clients that support this functionality. Also, if a feature is widely supported by one but not the other (in lots of feeds but not lots of aggregators) then I'd claim it isn't "significantly deployed". ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 14 18:13:09 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 SAA12920 for ; Thu, 14 Oct 2004 18:13:08 -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 i9EM4q17063560; Thu, 14 Oct 2004 15:04: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 i9EM4qHO063559; Thu, 14 Oct 2004 15:04:52 -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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EM4pQT063552 for ; Thu, 14 Oct 2004 15:04:51 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so350519rnk for ; Thu, 14 Oct 2004 15:04:56 -0700 (PDT) Received: by 10.38.8.35 with SMTP id 35mr440780rnh; Thu, 14 Oct 2004 15:04:56 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 14 Oct 2004 15:04:56 -0700 (PDT) Message-ID: <1f2ed5cd041014150422635e50@mail.gmail.com> Date: Fri, 15 Oct 2004 00:04:56 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: atom:link state of play Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 13 Oct 2004 17:35:24 -0700, Tim Bray wrote: > 4. Extensibility > Furthermore, I challenged the WG > (http://imc.org/atom-syntax/mail-archive/msg10471.html) as to whether > we really had to do extensible generalized links. It got one solid > "yes" from Danny Ayers (but Rob Sayre pushed back hard), one > sort-kinda-yes from Dare Obsanjo ("I'm partial to allowing some form of > extensibility in link constructs IFF a clear and concise definition of > what it means to be 'link' makes it into the spec.") and one > interesting counter-proposal from Sayre > (http://imc.org/atom-syntax/mail-archive/msg10481.html) which I don't > think is a Pace yet. I ran Robert's suggestion across the RDF lists and got quite a bit of response (some of which you probably saw cross-posted, when time permits I'll glue the core bits together and post). Opinions varied, but were generally positive - I don't think there were any "that's a bad idea" though naturally there were a few "here's a better idea (called RDF)" . I personally think having an extensible could be nice sugar (probably using URIs in @rel), but I'm fairly sure exactly the same data could be delivered using the mechanism Robert sketched. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 14 18:23:59 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 SAA14583 for ; Thu, 14 Oct 2004 18:23:58 -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 i9EMGTGG064973; Thu, 14 Oct 2004 15:16:29 -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 i9EMGTZv064972; Thu, 14 Oct 2004 15:16:29 -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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EMGSqL064966 for ; Thu, 14 Oct 2004 15:16:29 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so351113rnk for ; Thu, 14 Oct 2004 15:16:33 -0700 (PDT) Received: by 10.38.8.35 with SMTP id 35mr444630rnh; Thu, 14 Oct 2004 15:16:33 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 14 Oct 2004 15:16:33 -0700 (PDT) Message-ID: <1f2ed5cd04101415162853be95@mail.gmail.com> Date: Fri, 15 Oct 2004 00:16:33 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: atom:link state of play Cc: Tim Bray , mint@franklinmint.fm, Atom Syntax , Sam Ruby In-Reply-To: <20041014214121.34793.qmail@web41210.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> <20041014214121.34793.qmail@web41210.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 14 Oct 2004 14:41:21 -0700 (PDT), Dare Obasanjo wrote: > > > --- Tim Bray wrote: > > > > D'oh, of course. Given content @src, drop > > attachment/enclosure/whatever > > > > That would leave us with alternate|related for sure, > > and Sam claims > > that "via" and "comments" are significantly > > deployed, other voices pro > > or contra? > > If this is the case I'd like this claim backed up with > the number of feeds and clients that support this > functionality. Also, if a feature is widely supported > by one but not the other (in lots of feeds but not > lots of aggregators) then I'd claim it isn't > "significantly deployed". I think there's a strong case for both even if there isn't significant deployment. Many sites feature comments feeds, they are usually in an RSS format so will have general client support. The HTML weblog allows simple movement between main content of an item and its comments, the aggregator should be able to do that too. "via" is on the one hand useful as a courtesy, on the other as a potential means of tracking the source path of content. Both desirable, little cost. Consider this a feature request for RSS Bandit. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 14 18:39:49 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 SAA15729 for ; Thu, 14 Oct 2004 18:39:48 -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 i9EMUmrg066665; Thu, 14 Oct 2004 15:30: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 i9EMUmKc066664; Thu, 14 Oct 2004 15:30:48 -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 i9EMUlX1066657 for ; Thu, 14 Oct 2004 15:30:47 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CIE7R-0004LP-3c; Thu, 14 Oct 2004 22:30:45 +0000 Message-ID: <416EFE0F.90105@franklinmint.fm> Date: Thu, 14 Oct 2004 18:30:39 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Dare Obasanjo , Tim Bray , Atom Syntax , Sam Ruby Subject: Re: atom:link state of play References: <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> <20041014214121.34793.qmail@web41210.mail.yahoo.com> <1f2ed5cd04101415162853be95@mail.gmail.com> In-Reply-To: <1f2ed5cd04101415162853be95@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Thu, 14 Oct 2004 14:41:21 -0700 (PDT), Dare Obasanjo wrote: > >> >>--- Tim Bray wrote: >> >>>That would leave us with alternate|related for sure, >>>and Sam claims >>>that "via" and "comments" are significantly >>>deployed, other voices pro >>>or contra? >> >>If this is the case I'd like this claim backed up with >>the number of feeds and clients that support this >>functionality. Also, if a feature is widely supported >>by one but not the other (in lots of feeds but not >>lots of aggregators) then I'd claim it isn't >>"significantly deployed". > I reject the terms of this debate :) If we observe overloading of an element with divergent concepts, that's a sign of a design flaw. The number of people that write "via: ___" in their content is proof enough, IMO. We are not here to collect all the popular extensions to other formats under one namespace. There are a couple things that just need fixing. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 14 20:22:50 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 UAA24255 for ; Thu, 14 Oct 2004 20:22:49 -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 i9F0DYT9079023; Thu, 14 Oct 2004 17:13: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 i9F0DYsr079022; Thu, 14 Oct 2004 17:13:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0DWVR078939 for ; Thu, 14 Oct 2004 17:13:33 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 15 Oct 2004 10:13:16 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Oct 2004 10:06:21 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/10/04 6:33 AM, "Tim Bray" wrote: > Given content @src, drop attachment/enclosure/whatever use case: I write a blog posting reviewing some latest hit. It's full of my opinion and observations. should this be done like this: my latest hit single blah blha blah [... id, date, etc ...] or like this: my latest hit single blah blha blah [... id, date, etc ...] e. From owner-atom-syntax@mail.imc.org Thu Oct 14 20:23:16 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 UAA24310 for ; Thu, 14 Oct 2004 20:23:15 -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 i9F0ECbZ079119; Thu, 14 Oct 2004 17:14: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 i9F0ECkp079118; Thu, 14 Oct 2004 17:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F0EBE3079110 for ; Thu, 14 Oct 2004 17:14:12 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 15 Oct 2004 10:14:26 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Oct 2004 10:14:12 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/10/04 5:39 AM, "Tim Bray" wrote: >> I'm not sure where these came from. Who has deployed "about"? >> "attachment"? > > The deployment of "about" is in some part an artifact of the fuzziness > of the definition of in RSS, and to this day I encounter feed > items which, when I click on them, I get sent to whatever they're > talking about. I do claim it's a widely-deployed semantic. so you mean deployed as a semantic, but not necessarily as a syntax? >> "alternate", "related", "via", and "comments". > > "related" is more or less "about"? Not really. If say I wrote a blog posting about a new release movie then the 'alternate' link would point to my blog page, the 'about' link would point to the movie site, and 'related' might point to a review on some third party site, the previous episode in the movie series, a snarky fansite, or whatever else is related to {my blog post+the movie site}. (eg. if I was criticising a cops & robbers movie, I might also link to current crime statistics as 'related') > I've never used software that actually did anything intelligent with > "via" or "comments" links, but if people generally agree with Sam that > they're actually in use out there, that's fine with me. -Tim I'm writing scripts to plug into NNW which will find extra links and insert them into the . I can imagine the likes of technorati doing something interesting with 'via'. e. From owner-atom-syntax@mail.imc.org Thu Oct 14 20:38:24 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 UAA25105 for ; Thu, 14 Oct 2004 20:38:24 -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 i9F0U2Pn081641; Thu, 14 Oct 2004 17:30: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 i9F0U29B081640; Thu, 14 Oct 2004 17:30:02 -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 i9F0U2sh081629 for ; Thu, 14 Oct 2004 17:30:02 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CIFyu-0001RE-6k; Fri, 15 Oct 2004 00:30:06 +0000 Message-ID: <416F1A05.9020403@franklinmint.fm> Date: Thu, 14 Oct 2004 20:29:57 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: atom:link state of play References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 15/10/04 6:33 AM, "Tim Bray" wrote: > > >>Given content @src, drop attachment/enclosure/whatever > > > use case: I write a blog posting reviewing some latest hit. It's full of my > opinion and observations. > You can't have multiple content elements anymore (*stares at format draft), so you have to decide which is more to the point. blah blah or maybe or maybe the latest hit bla bla go to the links The salient point being that you haven't told us anything special if you refuse to focus on one URI (or tree of child content). Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 14 21:46:27 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 VAA29244 for ; Thu, 14 Oct 2004 21:46:26 -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 i9F1cRZD091744; Thu, 14 Oct 2004 18:38:27 -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 i9F1cRAt091743; Thu, 14 Oct 2004 18:38:27 -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 i9F1cPb4091735 for ; Thu, 14 Oct 2004 18:38:26 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i9F1dCKi023217; Thu, 14 Oct 2004 21:39:13 -0400 Message-ID: <416F2A16.1070003@intertwingly.net> Date: Thu, 14 Oct 2004 21:38:30 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: atom:link state of play References: 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 Eric Scheid wrote: > On 15/10/04 6:33 AM, "Tim Bray" wrote: > > >>Given content @src, drop attachment/enclosure/whatever > > use case: I write a blog posting reviewing some latest hit. It's full of my > opinion and observations. > > should this be done like this: > > > my latest hit single > blah blha blah > > [... id, date, etc ...] > Was this a typo? If the first element were a what you would be doing would be syndicating a mp3, and providing an accessible summary. This doesn't sound like a review. > or like this: > > > my latest hit single > blah blha blah > > [... id, date, etc ...] > In this case, whare you are syndicating is the text - the review itself. And providing a link to something related that somebody might (optionally) want to download. This sounds closer to the use case you described. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 14 21:49: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 VAA29303 for ; Thu, 14 Oct 2004 21:49: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 i9F1gcRw092222; Thu, 14 Oct 2004 18:42:38 -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 i9F1gces092221; Thu, 14 Oct 2004 18:42:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F1gap4092213 for ; Thu, 14 Oct 2004 18:42:37 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 15 Oct 2004 11:42:50 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Oct 2004 11:42:36 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <416F2A16.1070003@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/10/04 11:38 AM, "Sam Ruby" wrote: >> should this be done like this: >> >> >> my latest hit single >> blah blha blah >> >> [... id, date, etc ...] >> > > Was this a typo? If the first element were a what > you would be doing would be syndicating a mp3, and providing an > accessible summary. This doesn't sound like a review. not a typo. I just didn't feel like typing all 1500+ words of an example review for this email. I guess the only typo is leaving out [...] from the first content. >> or like this: >> >> >> my latest hit single >> blah blha blah >> >> [... id, date, etc ...] >> > > In this case, whare you are syndicating is the text - the review itself. > And providing a link to something related that somebody might > (optionally) want to download. This sounds closer to the use case you > described. that's my thinking too. so content/@src is no replacement for link/@rel='enclosure' then? e. From owner-atom-syntax@mail.imc.org Thu Oct 14 22:08:23 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 WAA00166 for ; Thu, 14 Oct 2004 22:08:23 -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 i9F1xkWv094383; Thu, 14 Oct 2004 18:59: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 i9F1xkK7094382; Thu, 14 Oct 2004 18:59:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9F1xj7j094370 for ; Thu, 14 Oct 2004 18:59:45 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041015015946.78918.qmail@web41207.mail.yahoo.com> Received: from [131.107.71.94] by web41207.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 18:59:46 PDT Date: Thu, 14 Oct 2004 18:59:46 -0700 (PDT) From: Dare Obasanjo Subject: Re: atom:link state of play To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > > > And providing a link to something related that > somebody might > > (optionally) want to download. This sounds closer > to the use case you > > described. > > that's my thinking too. so content/@src is no > replacement for > link/@rel='enclosure' then? *chuckle* It depends on what you think the semantics of enclosure are. If you mean "here's some bits you can download" then it does. Considering that's the only semantic of RSS enclosures that exists today I'm not sure why you think it isn't a replacement. It seems you are trying to differentiate between when the rich content is the content of the entry and when it is related to the content of the entry which is a distinction that doesn't exist in RSS enclosures. You are fond of claiming that all link semantics are the same but now you seem not to think so. So which is it? To put this in perspective of an aggregator, I can imagine a user wanting to download all MP3 contents from a feed (e.g. podcasts) but wanting the opposite on a review site which provides a handy link to an MP3 of the reviewed song. In RSS today there is no way to distinguish between both cases. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 14 23:59:39 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 XAA05596 for ; Thu, 14 Oct 2004 23:59:38 -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 i9F3nwCS010664; Thu, 14 Oct 2004 20:49:58 -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 i9F3nwAV010663; Thu, 14 Oct 2004 20:49:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F3nubd010604 for ; Thu, 14 Oct 2004 20:49:57 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 15 Oct 2004 13:49:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Oct 2004 13:49:27 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041015015946.78918.qmail@web41207.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/10/04 11:59 AM, "Dare Obasanjo" wrote: > It depends on what you think the semantics of > enclosure are. If you mean "here's some bits you can > download" then it does. Considering that's the only > semantic of RSS enclosures that exists today I'm not > sure why you think it isn't a replacement. It seems > you are trying to differentiate between when the rich > content is the content of the entry and when it is > related to the content of the entry which is a > distinction that doesn't exist in RSS enclosures. well silly me. my mental model for "enclosures" has been the same as "attachments" in email ... blobs of stuff sent along *with* an actual message. The RSS2 doesn't make any distinction either way. It certainly doesn't say something like "if is present then must only be a summary or be absent". The element can co-exist with the element, and the element can be and often is full content. > You are fond of claiming that all link semantics are > the same but now you seem not to think so. So which is > it? Non-sequitor. content/@src are not s. I've never made any such claim. You are fond of claiming that there are differences while at the same time refusing to elucidate on those differences. So just how are the semantics for the two cases here any different? (1) review feed: entry has long review content and enclosure link to the thing being reviewed ... if this was a review source I trust and am interested in, then I'd want to prefetch the linked enclosure. (2) podcasting feed: entry has just a text title, maybe a summary, and a link to an enclosure ... again, if this was content I'm interested in I would want to prefetch the linked enclosure. So how are the semantics different? This does raise an interesting question though: if an entry has both a and a , would an aggregator display both? What if they summary was @type="text/plain" and the content was @src="some.mp3"? > To put this in perspective of an aggregator, I can > imagine a user wanting to download all MP3 contents > from a feed (e.g. podcasts) but wanting the opposite > on a review site which provides a handy link to an MP3 > of the reviewed song. In RSS today there is no way to > distinguish between both cases. depends on the user and the feed. I subscribe to D. Keith Robinson's feed, which is mostly web-development/web-standards postings, but he also posts a Song Of The Week entry every week -- an extended review, with links, and "Recommended if you like", and a link to the mp3. I'd want to download that. If there was some feed dedicated to just reviews, and of which I'm simply not interested in reading every review because they cover both kinds of music (country AND western!), then I'd not want to waste my bandwidth downloading every enclosure. On the other hand if I'm a music nut with too much time and bandwidth on my hands, I might well want to download all the enclosures on Rolling Stone's music review feed and also their movie review feed (assuming links to preview clips). Similarly, if I just plain didn't like DKR's taste in music then I wouldn't want to auto-fetch the songs he reviews, despite wanting to read all his other postings. My aggregator lets me choose how often I poll my subscriptions on a per subscription basis. It also lets me set how much history to retain per subscription on a per subscription basis. Setting whether I want to auto-fetch enclosures should also be a per-subscription preference. e. From owner-atom-syntax@mail.imc.org Fri Oct 15 00:59: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 AAA08505 for ; Fri, 15 Oct 2004 00:59: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 i9F4ncbH018761; Thu, 14 Oct 2004 21:49:38 -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 i9F4nc9n018760; Thu, 14 Oct 2004 21:49:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41204.mail.yahoo.com (web41204.mail.yahoo.com [66.218.93.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9F4nc5F018753 for ; Thu, 14 Oct 2004 21:49:38 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041015044930.53027.qmail@web41204.mail.yahoo.com> Received: from [24.18.132.123] by web41204.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 21:49:30 PDT Date: Thu, 14 Oct 2004 21:49:30 -0700 (PDT) From: Dare Obasanjo Subject: Re: atom:link state of play To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > My aggregator lets me choose how often I poll my > subscriptions on a per > subscription basis. It also lets me set how much > history to retain per > subscription on a per subscription basis. Setting > whether I want to > auto-fetch enclosures should also be a > per-subscription preference. You're right. This should be a user controlled feature not something dictated by the publisher of the feed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 15 03:50: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 DAA02712 for ; Fri, 15 Oct 2004 03:50: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 i9F7aYqb093673; Fri, 15 Oct 2004 00:36: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 i9F7aYhP093672; Fri, 15 Oct 2004 00:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F7aWCp093473 for ; Fri, 15 Oct 2004 00:36:33 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 15 Oct 2004 17:36:10 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 15 Oct 2004 17:35:56 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041015044930.53027.qmail@web41204.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/10/04 2:49 PM, "Dare Obasanjo" wrote: >> My aggregator lets me choose how often I poll my subscriptions on a per >> subscription basis. It also lets me set how much history to retain per >> subscription on a per subscription basis. Setting whether I want to >> auto-fetch enclosures should also be a per-subscription preference. >> > You're right. This should be a user controlled feature not something dictated > by the publisher of the feed. > although, the publisher should get some say in what links are suitable for auto-fetching, and which are not. robots.txt normally handles that aspect pretty well, despite the usual problems with robots.txt in certain environments. There is however a grey area use-case... consider how pre-fetching works with the mozilla browser: a user requests a page, and the browser automatically loads the images, so far all is normal, but mozilla will also look for links on that page that are marked 'prefetch' and will start downloading them shortly after all other inline resources have been retrieved. Thus, if the user then clicks on the link to the next page they can find that it is already locally cached. I can imagine a similar usage scenario with an aggregator - it doesn't pre-fetch linked enclosures at night, but instead waits until I click to read (say) the long review. While I'm reading that review the enclosure is downloading, and when I'm done it's there ready for me to listen to. So, in a world where publishers are complaining about bandwidth drains, they just might like the opportunity of being able to say "this particular file I don't mind if you auto download". So while robots.txt is restrictive, 'prefetch' is permissive. e. From owner-atom-syntax@mail.imc.org Fri Oct 15 07:34:27 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 HAA19196 for ; Fri, 15 Oct 2004 07:34:26 -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 i9FBMftn080840; Fri, 15 Oct 2004 04: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 i9FBMfBb080839; Fri, 15 Oct 2004 04:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FBMdkK080829 for ; Fri, 15 Oct 2004 04:22:40 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9FBGAFB004015; Fri, 15 Oct 2004 12:16:15 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--727316060; protocol="application/pkcs7-signature" Message-Id: <9CAD4072-1E9B-11D9-94E9-000A2797ECDA@mac.com> Cc: Atom Syntax From: Graham Subject: Re: atom:link state of play Date: Fri, 15 Oct 2004 12:16:06 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--727316060 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 15 Oct 2004, at 2:42 am, Eric Scheid wrote: > that's my thinking too. so content/@src is no replacement for > link/@rel='enclosure' then? Yes. The RSS enclosure element is a far better match for most proposed uses of content @src. btw I much prefer "attachment" to "enclosure", as it's far less misleading. Graham --Apple-Mail-2--727316060 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE1MTExNjA2WjAjBgkqhkiG9w0BCQQxFgQU5IedBYcX8X6llPmYnvMpPVQv 2rsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAI+j2ug00n2hTy79kdOMYyVGP U/xCEeHmFrU5ZaFvQEdPoKfuxHuEGT5gJ61mbCeIRSMdfJsKaUiNxFpIwcbL94enqvkTVoDaGSRx jGaFx/074ZTcJzeUMQoRthb0lj6y4lyx+pZUKoICs+G2PQw6xMxxe7dWNS4SGM1TO8rR20lvz1pz Owa2b2c5dy4sjTDxP2CQb6pAtGFEcasKUoHvuCMgn+bWymSkzzUwwBREgg5GADB+/LxL+cwJxG3s BUapq7OYXYW4dXvzBtwx+EZycHQH8hahBjZ88a2dgOWdCRxtfcA2bVKFu5ahI6uh1O94wige2ZqE 8LlBjwnTtYWTEAAAAAAAAA== --Apple-Mail-2--727316060-- From owner-atom-syntax@mail.imc.org Fri Oct 15 08:36: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 IAA23413 for ; Fri, 15 Oct 2004 08:36: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 i9FCRsBs089201; Fri, 15 Oct 2004 05:27:54 -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 i9FCRsRV089200; Fri, 15 Oct 2004 05:27:54 -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 i9FCRrWe089194 for ; Fri, 15 Oct 2004 05:27:53 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.100] (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 i9FCSaej024906; Fri, 15 Oct 2004 08:28:36 -0400 Message-ID: <416FC248.9010709@intertwingly.net> Date: Fri, 15 Oct 2004 08:27:52 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: mint@franklinmint.fm, Atom Syntax Subject: Re: atom:link state of play References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <416EE048.5010202@franklinmint.fm> <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> In-Reply-To: <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> 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 Tim Bray wrote: > > On Oct 14, 2004, at 1:23 PM, Robert Sayre wrote: > >> If we have content @src, we don't need it. I think it would be totally >> cool if we renamed to something like , but it's not a >> big deal. > > D'oh, of course. Given content @src, drop attachment/enclosure/whatever > > That would leave us with alternate|related for sure, and Sam claims that > "via" and "comments" are significantly deployed, other voices pro or > contra? This is looking more and more like: http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Oct 15 09:43: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 JAA28953 for ; Fri, 15 Oct 2004 09:42:59 -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 i9FDXeDC094271; Fri, 15 Oct 2004 06:33: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 i9FDXeDB094270; Fri, 15 Oct 2004 06:33:40 -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 i9FDXeN3094261 for ; Fri, 15 Oct 2004 06:33:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CISD8-0008JA-NE; Fri, 15 Oct 2004 13:33:34 +0000 Message-ID: <416FD1AA.20509@franklinmint.fm> Date: Fri, 15 Oct 2004 09:33:30 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Eric Scheid , Atom Syntax Subject: Re: atom:link state of play References: <9CAD4072-1E9B-11D9-94E9-000A2797ECDA@mac.com> In-Reply-To: <9CAD4072-1E9B-11D9-94E9-000A2797ECDA@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > btw I much prefer "attachment" to "enclosure", as it's far less misleading. Since the resource isn't enclosed or attached, I don't understand. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 15 09:44:29 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 JAA29122 for ; Fri, 15 Oct 2004 09:44:29 -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 i9FDa5Xo094445; Fri, 15 Oct 2004 06:36:05 -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 i9FDa5lq094444; Fri, 15 Oct 2004 06:36:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FDa4mh094437 for ; Fri, 15 Oct 2004 06:36:05 -0700 (PDT) (envelope-from Janne.Jalkanen@nokia.com) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FDa5h15273 for ; Fri, 15 Oct 2004 16:36:05 +0300 (EET DST) X-Scanned: Fri, 15 Oct 2004 16:35:40 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9FDZexJ022756 for ; Fri, 15 Oct 2004 16:35:40 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 004jJmAC; Fri, 15 Oct 2004 16:35:39 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FDZdS22493 for ; Fri, 15 Oct 2004 16:35:39 +0300 (EET DST) Received: from [172.21.50.245] ([172.21.50.245]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Oct 2004 16:35:36 +0300 Message-ID: <416FD229.2040305@nokia.com> Date: Fri, 15 Oct 2004 16:35:37 +0300 From: Janne Jalkanen User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: fi, en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: atom:link state of play References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2004 13:35:36.0777 (UTC) FILETIME=[DA819390:01C4B2BB] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > And if we *can't* get consensus on this list, I say the hell with it, > just have an with no @rel, used for what we now call > rel='alternate', and leave the rest for extensions. -Tim +1 for . If the list can't agree on it, it is probably too complex anyway - so a simple, extensible solution, that perhaps does not do everything, but does one thing well, might be the best choice. /Janne From owner-atom-syntax@mail.imc.org Fri Oct 15 11:03:33 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 LAA11165 for ; Fri, 15 Oct 2004 11:03:32 -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 i9FErUWZ000587; Fri, 15 Oct 2004 07:53:30 -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 i9FErUts000586; Fri, 15 Oct 2004 07:53:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FErTCV000579 for ; Fri, 15 Oct 2004 07:53:29 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9FErVNH028571 for ; Fri, 15 Oct 2004 08:53:31 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5M000YCS1746@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 15 Oct 2004 08:53:31 -0600 (MDT) Received: from [192.168.1.24] ([204.174.35.171]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5M00LCFS14SV@mail.sun.net> for atom-syntax@imc.org; Fri, 15 Oct 2004 08:53:29 -0600 (MDT) Date: Fri, 15 Oct 2004 07:53:51 -0700 From: Tim Bray Subject: Re: atom:link state of play In-reply-to: <416FC248.9010709@intertwingly.net> To: Sam Ruby Cc: Atom Syntax , mint@franklinmint.fm Message-id: <06E1AA66-1EBA-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <416EE048.5010202@franklinmint.fm> <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> <416FC248.9010709@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 15, 2004, at 5:27 AM, Sam Ruby wrote: >> D'oh, of course. Given content @src, drop >> attachment/enclosure/whatever >> That would leave us with alternate|related for sure, and Sam claims >> that "via" and "comments" are significantly deployed, other voices >> pro or contra? > > This is looking more and more like: > > http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults Yes, except for we're talking about having an IANA registry to allow for extensibility, albeit with some difficulty. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 15 13:23: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 NAA22206 for ; Fri, 15 Oct 2004 13:23:34 -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 i9FHCh8S015453; Fri, 15 Oct 2004 10:12:43 -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 i9FHChnl015452; Fri, 15 Oct 2004 10:12:43 -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 i9FHCfjV015444 for ; Fri, 15 Oct 2004 10:12:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CIVd9-00028a-JT; Fri, 15 Oct 2004 17:12:39 +0000 Message-ID: <41700505.80603@franklinmint.fm> Date: Fri, 15 Oct 2004 13:12:37 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Tim Bray , Atom Syntax Subject: Re: atom:link state of play References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <416EE048.5010202@franklinmint.fm> <4056FB9A-1E20-11D9-A19B-000A95A51C9E@sun.com> <416FC248.9010709@intertwingly.net> In-Reply-To: <416FC248.9010709@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: > >> >> D'oh, of course. Given content @src, drop attachment/enclosure/whatever >> >> That would leave us with alternate|related for sure, and Sam claims >> that "via" and "comments" are significantly deployed, other voices pro >> or contra? > > > This is looking more and more like: > > http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults Off list, it has been pointed out to me that people often "blog about" other resources (duh!), and content @src is badly overloaded if used as "about". It makes sense to use content @src for flickr, or the Gillmor Gang. Other stuff I'm not so sure about. Then, we're getting into a situation where is the thing you click to, but if it's not there, then there's alternate, or maybe content @src... so to be safe, put the same URI in all of em... I'm thinking maybe we won't have a good handle on this problem until we deal with extensibility. This discussion seems to be proof that we are not getting it right. "Get it right If you haven't gone to the trouble of making a semantic model, then you may not have a well defined one."[0] Let's also keep MarkP's wise words[1] about RDF discussions in mind. Our conceptual model needs some help. I am not talking about RDF syntax, RDF tools, or the Semantic Web. Robert Sayre [0] http://www.w3.org/DesignIssues/RDF-XML.html [1] http://www.xml.com/pub/a/2003/08/20/dive.html --------------------------------------------------- The Gillmor Gang in imaginary syntax: Gilmor Gang ... 2004-09-24T16:45:37Z IT Conversations http://itconversations.com/ ... blah blah Anil Dash's linkblog in Atom 0.3: Note that Anil has switched some stuff around on us, because Atom 0.3 isn't quite right. How should this be written in the syntax above? Anil wants the "click event" to take the user to the cruftbox.com page. HOT SAUCE CLEANS PENNIES 2004-09-24T11:45:01-05:00 ... 2004-09-24T16:45:01Z talk about getting things done! anildash http://anildash.com/ anil@dashes.com http://cruftbox.com/blog/archives/001034.html... Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 15 17:22:44 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 RAA23273 for ; Fri, 15 Oct 2004 17:22: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 i9FLAZvG055121; Fri, 15 Oct 2004 14:10:35 -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 i9FLAYGL055120; Fri, 15 Oct 2004 14:10:35 -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 i9FLAYqf055110 for ; Fri, 15 Oct 2004 14:10:34 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CIZLM-00050H-3R; Fri, 15 Oct 2004 21:10:32 +0000 Message-ID: <41703CC4.6090302@franklinmint.fm> Date: Fri, 15 Oct 2004 17:10:28 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Kill PaceLinkConstruct References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > > The following Paces are clinging to life, have a single -1 but aren't > being strung up to the rafters by a howling mob: > > PaceLinkConstruct (adds rev="comment|update|replaces") > ... I wrote this one. I've never said anything good about it, and I've usually had company when giving it the -1. Whatever we decide, it's safe to say that none of that Pace is going to make it in. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 16 10:01: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 KAA21809 for ; Sat, 16 Oct 2004 10:01:13 -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 i9GDp0P1085012; Sat, 16 Oct 2004 06:51:00 -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 i9GDp0Mr085011; Sat, 16 Oct 2004 06:51:00 -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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9GDp0qP084995 for ; Sat, 16 Oct 2004 06:51:00 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id 80so30503rnl for ; Sat, 16 Oct 2004 06:50:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nHH8jbL0kSBm4WWuvxocF/w9Y693246W82T5R188ADlHSflU/sJvY4as+UFk5FkYOx3NTHInLxV9b2ALP4DJN+wlyDppWI4kDOqJC53Kyf9k1qcY+w+CI5L4snPcw/4x1+E0ABB9hckSFvc68FQMgrcehMyzsNc/AQQDCRqXSmA Received: by 10.38.8.13 with SMTP id 13mr945568rnh; Sat, 16 Oct 2004 06:50:55 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 16 Oct 2004 06:50:55 -0700 (PDT) Message-ID: <1f2ed5cd04101606505a68488b@mail.gmail.com> Date: Sat, 16 Oct 2004 15:50:55 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Antone Roundy Subject: Re: Separating Link Concerns Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <416BEA43.2090104@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry Antone, I only just spotted your post. On Tue, 12 Oct 2004 12:44:11 -0600, Antone Roundy wrote: > > On Tuesday, October 12, 2004, at 08:29 AM, Sam Ruby wrote: > > It looks to me like PaceLinkRelPrefixReg and PaceRelationshipConstruct > > are taking that atom:link element in two different directions. > > I'm having a difficult time wrapping my brain around > PaceRelationshipConstruct and figuring out how Atom would benefit from > it. Here's what I'm getting: > > * if an element has @atom:href > * then > + we know that what it points to is somehow related to the parent > element > * and > + if we recognize the element, we also know whatever other things that > element tells us, which are different on an element-by-element basis > + else we don't know anything else about it > > Unless there's more to it than that, then I don't see the benefit. > Basically, we know that atom:href points to something. It also points *from* something, and a relationship is defined. > The proposed spec text is pretty cryptic to one like I who is not > versed in the kind of thing (RDF, I assume) that it is based on. It's based on the URI definition of a resource, XML and XML namespaces. Sorry if it seems cryptic, my bad, but I was trying to be formal & unambiguous. (Heh, I used 'relationship' rather than 'relation' to avoid opening another can of worms - looks like I forget to remove the can opener). Do we > need to say "binary"? What does that mean, exactly, that isn't > communicated without the word "binary"? "The nature of the > relationship is determined by the name of the element...". Yep, "binary" is redundant. Okay, > that's saying that there's no @rel to define the nature of the > relationship. I'm not sure we need that sentence, because I think > that's what would be expected, absent mention of some other method of > determining the nature of the relationship. I think it worthwhile making it explicit, as other interpretations may be possible. > The next sentence: "If that name is in the Atom namespace, then a > consumer MUST interpret it and behave according to the definition of > that term in this specification." That goes without saying, I think. Yep, but again it's making it explicit to preempt any confusion. > Next: "Otherwise the consumer MAY follow whatever definition is > provided for the the term in the namespace in question." I don't > suppose this is intended to imply that consumers are free to > misinterpret elements from other namespaces. Yes, exactly that, as far as Atom is concerned. I don't know that we need > this sentence. Next: "If the consumer has no knowledge of the term > then it MAY ignore it or present the data to the end user in any manner > deemed appropriate." It goes without saying that unrecognized elements > from other namespaces can be ignored (unless we add some sort of > "mustUnderstand" mechanism). They could be treated as errors or take some other interpretation defined elsewhere. What manner could possible seem > appropriate to present an element that you only know one thing about: > there's something out there that's related to the parent element? At minimum you know three things: 1. the subject of the relation (the resource associated with the parent element) 2. the name of the relation (the namespace-qualified element name) 3. the object of the relation Through RDF spectacles this is very useful. Without those spectacles, how's this scenario: an aggregator stores the complete feed data it reads. Version 1.0 of the aggregator doesn't recognise relationX. But version 2.0 does, so after upgrade your tool can present stored data which includes relationX in an appropriate fashion. > I guess I'm just not catching the vision. Would it not be more useful > to be able to tie extension elements to a more tightly defined Atom > construct, which would give the consumer some basis for applying > default processing? Maybe, that's kind-of territory. Would not unknown extension elements be pretty > much equally useful without knowing the one piece of information that > the Relationship Construct gives us? In other words, how much more can > an application do with: > > My data > > than with: > > My data Nice example. The application can answer the questions: "are there any other resources related to this (parent element) resource" and "what are the names of those relationships". What it does with that information is another question (e.g. it could try and find out what the relationship means) but the difference is that /something/ rather than /nothing/ is communicated. > > I've started to pull together a PaceMetaElement in the hopes that > > these goals to be pursued separately and without compromise. [snip - I've still not checked this out, the days are definitely getting shorter...] Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 16 13:46: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 NAA04797 for ; Sat, 16 Oct 2004 13:46:39 -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 i9GHYciW016710; Sat, 16 Oct 2004 10:34:38 -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 i9GHYcEl016709; Sat, 16 Oct 2004 10:34:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9GHYbjO016701 for ; Sat, 16 Oct 2004 10:34:37 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9GHYeui010141 for ; Sat, 16 Oct 2004 11:34:41 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5O0010PU5SX6@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 16 Oct 2004 11:34:40 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5O00FOCU5RMI@mail.sun.net> for atom-syntax@imc.org; Sat, 16 Oct 2004 11:34:40 -0600 (MDT) Date: Sat, 16 Oct 2004 10:35:04 -0700 From: Tim Bray Subject: Bell on Standards To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--618180020; protocol="application/pkcs7-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-8--618180020 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Here's some homework, a reading assignment for the WG: http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=210 --Apple-Mail-8--618180020 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwuKuTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMTIyMjMzOTA2WhcNMDUwMTIxMjMzOTA2WjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhR0YnJheUB0ZXh0dWFsaXR5 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMYiIlrf7yTblabXBlwkonodVyp+ W7Oo8w71ErSW7mKramEBAkfkUnPmbRqcS2wqFaK34GbQMk/1vcOxo2AmfmFVec13SWKi0YzXC8xf 9SbjfQU1tXiC9LJB1HeOO46UVRqTNeayruz2pQBztvYF76G5sGmwKjoR/DhimwUM579MaJln38SK UQ6Ya768DwyaDNY7yDWYh1gUxizx71QkzyRCPQdmq6g1ebrVYyoBE33BXQRNGZm2zrlI5JBQ4oax E0Cz3BjR8iZFzK/AhFGDllZYuojf7iZuaNhWr3aWAvHNyLHVMaxXNFb/CUri5c7StFVEgXUVvlgP eSHIPg9gqaECAwEAAaMxMC8wHwYDVR0RBBgwFoEUdGJyYXlAdGV4dHVhbGl0eS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBQAlJ/qQJmtQN966ahSWiovhjWj5Qwk6BnPP+Fjfbo 9guSIWWBw2DEXh8nPT4WJchZSVz4SwDtZ0SZ2PWWToRo/Dmpv+ehzNNhR/y2CdU/zNo+kSShBhc6 HNtp6A0+Yh6Vw0Y+qHa0EKppOJM2D5WTExycYjHU8Xs+dLktAmKqlzCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTAxNjE3MzUwNFowIwYJKoZIhvcNAQkEMRYEFHLg 5IFWNQ1xFsPWCnT/hKSGmlR4MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAChW EdOncXu/GudjdRCLIjFVoYpN5TYEyYHp4OomL3FJqq1pJ8wZblmYMv73WdXwhn0wxCBq6G/n41E3 WH8CJDfvp9qVRl0EG5thQ//ZXkmiWzue7sbU1dBemFRnQo6Kzstg8agcsMn/KYt26N+BOEQHxjOx 4eS0zIVY1ZvNmBQj3p/t5LqI3jrQuAvRMR1xpWbLK74hgmeKF5NH0D8th5TiEd4X3iHr8sA5Nv+m rbiOL/WeovJN0R9HD7hjiI8gEfB0l9XOh8kHq35H+mXUIj7I+Y/23tTJRYgzv4I4pSU39MypD7ap 4i4vUFUw045eqANhJDMfkZnNBrNQoPTXC/gAAAAAAAA= --Apple-Mail-8--618180020-- From owner-atom-syntax@mail.imc.org Sat Oct 16 14:09: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 OAA06365 for ; Sat, 16 Oct 2004 14:09:16 -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 i9GI21xo020748; Sat, 16 Oct 2004 11:02:01 -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 i9GI21wL020747; Sat, 16 Oct 2004 11:02:01 -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 i9GI1xjI020726 for ; Sat, 16 Oct 2004 11:02:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CIssP-00025S-7G; Sat, 16 Oct 2004 18:01:57 +0000 Message-ID: <4171620F.80806@franklinmint.fm> Date: Sat, 16 Oct 2004 14:01:51 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom-Syntax Subject: Re: Separating Link Concerns References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <416BEA43.2090104@intertwingly.net> In-Reply-To: <416BEA43.2090104@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: > > > Summary: > > * service in a separate element +1. I see this Pace is in the accepted list[0], so it will be in format-03 > * meta in a separate element I agree with the goal of PaceMetaElement. It is useful for Atom to separate "hypertext linking" from URIs that are "logical information ... not intended to be browsed by people as a document." [1] > * link no longer required if content is present > * default values for link attributes for the common case > * link rel values subject to IANA registration. I strongly object to the link @rel syntax, and IANA registration. We have a thoroughly tested collision-avoidance mechanism that we use everywhere else: XML Namespaces. I think I understand why some favor the syntax. The draw seems to be its approachability. The problem with it is that people think they can use it exactly as they do in HTML, which is not what's being proposed. I have received off-list email from WG members that make this mistake--not a good sign. It seems worth it to call out hypertext links as special properties of an entry. I'd like to see how people respond to this: ... ... ... [undefined child content] ... This would make children of hypertext references, and the Link construct would leave child content undefined. Attribute defaults would be present. However, Atom core link elements would not allow child content. I'll write a Pace if this idea resonates. Thoughts? Robert Sayre [0] http://www.intertwingly.net/wiki/pie/AtomPubIssuesList [1] http://www.w3.org/DesignIssues/XLink.html (not saying we should use XLink :) ) From owner-atom-syntax@mail.imc.org Sat Oct 16 14:24:36 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 OAA06894 for ; Sat, 16 Oct 2004 14: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 i9GIHA9r022520; Sat, 16 Oct 2004 11:17:10 -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 i9GIHA98022519; Sat, 16 Oct 2004 11:17:10 -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 i9GIH9VK022513 for ; Sat, 16 Oct 2004 11:17:09 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CIt77-00057S-Gp; Sat, 16 Oct 2004 18:17:09 +0000 Message-ID: <4171659F.6080203@franklinmint.fm> Date: Sat, 16 Oct 2004 14:17:03 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Bell on Standards References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > Here's some homework, a reading assignment for the WG: > http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=210 That article is so worth it. Bullet point #1: * A standard delineates a point of homogeneity, enabling heterogeneity, change, and unbridled innovation in other areas. Reminded me of Matt Webb's excellent "This is About Atom" piece. http://interconnected.org/home/2004/08/16/this_is_about_atom Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 16 14:51:42 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 OAA07836 for ; Sat, 16 Oct 2004 14:51:41 -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 i9GIh3Dw026103; Sat, 16 Oct 2004 11:43:03 -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 i9GIh3YL026102; Sat, 16 Oct 2004 11:43:03 -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 i9GIh21J026096 for ; Sat, 16 Oct 2004 11:43:02 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CItW8-00013T-TT; Sat, 16 Oct 2004 18:43:01 +0000 Message-ID: <41716BAE.40309@franklinmint.fm> Date: Sat, 16 Oct 2004 14:42:54 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lucas@gonze.com CC: Atom Syntax Subject: atom:paperclip (was: atom:link state of play) References: <416ED26D.2080605@intertwingly.net> <416EDB73.1080804@intertwingly.net> <9C1AC85A-1E1E-11D9-A19B-000A95A51C9E@sun.com> <416EE60B.80206@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Lucas Gonze wrote: > On Thu, 14 Oct 2004, Robert Sayre wrote: > >> Lucas Gonze wrote: >> >>> >>> "prefetch" is an obvious candidate. The downside is that it doesn't >>> encompass all the uses supplied for the RSS 2.0 tag. >>> >> I'm confused. This is precisely the problem with that RSS2 tag. >> >> If you want to download something in the middle of the night, that's >> fine... I don't see why we should write it into the spec. > > > I don't know yet what I think about it, because I can't figure out why > the original enclosure tag accomplished anything at all. > There are some things that Dave has figured out pretty well. The main feature of is not prefetching or any such nonsense. It's the appearance of a paperclip icon in the user interface, just like email. This is subtly but critically different than content @src. So, I can see a use for a hypothetical element, and I agree with Graham and Eric now.[0] Still think "attachment" and "enclosure" are terrible names, but maybe that's the best we can do. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg10626.html From owner-atom-syntax@mail.imc.org Sun Oct 17 06:02:24 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 GAA08421 for ; Sun, 17 Oct 2004 06:02:24 -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 i9H9oYJ1035193; Sun, 17 Oct 2004 02:50: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 i9H9oYuC035192; Sun, 17 Oct 2004 02:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9H9oWNp035120 for ; Sun, 17 Oct 2004 02:50:32 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 36090 invoked by uid 17064); 17 Oct 2004 09:50:25 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.7.49]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Oct 2004 09:50:25 -0000 In-Reply-To: <4171659F.6080203@franklinmint.fm> References: <4171659F.6080203@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Robert Sayre From: Henry Story Subject: Re: Bell on Standards Date: Sun, 17 Oct 2004 11:50:21 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes, on the whole a good article. It fails to mention Java as an amazing standards setting success story even though it fully complies with his own stated requirement "faux standards such as SQL and Unix/Posix that failed to provide for the testing of interoperability and thus became little more than meaningless check-box requirements." This in any case is much too hard on unix than is reasonable, as many open source projects that have written software that compiles on these numerous so called, incompatible platforms have shown. Gorden Bell fails to see that unix has done to software what IBM did to hardware: completely componentize it around interfaces, and open up the flodgates of implementation competition. But then Gordon Bell is working for Microsoft, so this blindness is not so surprising. In any case just the first bullet point #1 A standard delineates a point of homogeneity, enabling heterogeneity, change, and unbridled innovation in other areas. Would tend to make me think that RDF is the solution, and so vote for RSS1.0, since it captures nicely the central needs but allows easy extensibility and innovation, building on a now well defined and mathematically backed up framework. I think all the other points for me tend to favor RSS1.0. In fact I still fail to see that Atom has much to offer beyond that. In any case I would be surprised to find that Atom had anything to offer which could not be done with a small extension to RSS1.0. Henry On 16 Oct 2004, at 20:17, Robert Sayre wrote: > > Tim Bray wrote: >> Here's some homework, a reading assignment for the WG: >> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=210 > > That article is so worth it. > > Bullet point #1: > > * A standard delineates a point of homogeneity, enabling > heterogeneity, change, and unbridled innovation in other areas. > > Reminded me of Matt Webb's excellent "This is About Atom" piece. > http://interconnected.org/home/2004/08/16/this_is_about_atom > > Robert Sayre > From owner-atom-syntax@mail.imc.org Sun Oct 17 13:26:04 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 NAA09190 for ; Sun, 17 Oct 2004 13:26: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 i9HHEb4g024298; Sun, 17 Oct 2004 10:14:37 -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 i9HHEbb1024297; Sun, 17 Oct 2004 10:14:37 -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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HHEa62024291 for ; Sun, 17 Oct 2004 10:14:36 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so46822rnb for ; Sun, 17 Oct 2004 10:14:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=aF0LHoJzYn/queK3GfkIyBsrGRMfWF+fcQt8EK3FNONtQO29CZdvGet7+8MJ3RiCDkK3DUM+roJvYo0l4b6qRR77jbLUwdEqV7ACS/EW0+ufMXbU0HIx4QSF0SZQvrMx2u6gEytVoZEbALeeBQUcso/1lw4xhQy/p3KUeK8pTP8 Received: by 10.38.98.26 with SMTP id v26mr184872rnb; Sun, 17 Oct 2004 10:14:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sun, 17 Oct 2004 10:14:39 -0700 (PDT) Message-ID: <1f2ed5cd041017101419b3247f@mail.gmail.com> Date: Sun, 17 Oct 2004 19:14:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Media (paper)clips article Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Contains some design discussion about XML attachments/enclosures in the context of video, SVG and SMIL. Note the correction at the bottom of the page: http://www.xml.com/pub/a/2004/10/13/sacre.html Following the references in that piece, I'm tempted* to say Atom should avoid NotInventedHere and ReinventingTheWheel and use (suitably namespace-qualified) SMIL elements, specifically its BasicMedia Module. See: http://www.w3.org/TR/smil20/extended-media-object.html#media-BasicMedia Cheers, Danny. * Only tempted, because like I keep saying, I don't believe implementation patterns necessarily make sense for specifications. http://c2.com/cgi/wiki?NotInventedHere http://c2.com/cgi/wiki?ReinventingTheWheel -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 17 20:25: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 UAA07577 for ; Sun, 17 Oct 2004 20:25:50 -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 i9I0FnwL084273; Sun, 17 Oct 2004 17:15:49 -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 i9I0FnJN084272; Sun, 17 Oct 2004 17:15:49 -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 i9I0FmxS084261 for ; Sun, 17 Oct 2004 17:15:48 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 474127C1EE; Mon, 18 Oct 2004 02:14:01 +0200 (CEST) Date: Mon, 18 Oct 2004 02:19:27 +0200 To: "Tim Bray" Subject: Re: atom:link state of play Cc: Atom-Syntax References: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 14 Oct 2004 10:30:28 -0700, Tim Bray wrote: > Specifically: "alternate", "about", and "attachment". Why can't we use words already known and used in Dublin Core? Or is Dublin Core to be considered as an extension to Atom whereas Atom _needs_ to make up its own named semantic in all places? I'm asking because I'm wondering. If we were to used Dublin Core's relational names here, 'hasFormat'[1], 'hasPart'[2], 'hasVersion'[3], 'isFormatOf'[4], 'isPartOf'[5], 'isReferencedBy'[6], 'isReplacedBy'[7], 'isRequiredBy'[8] and 'isVersionOf'[9] are all values we could adopt directly. If we're not to adopt them, I think we should at least consider the way they're defined, because they make very much sense in a publishing environment. ____ [1] [2] [3] [4] [5] [6] [7] [8] [9] -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Oct 18 03:02:22 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 DAA20402 for ; Mon, 18 Oct 2004 03:02:22 -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 i9I6omCm085038; Sun, 17 Oct 2004 23:50: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 i9I6omfW085037; Sun, 17 Oct 2004 23:50:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I6olsW085019; Sun, 17 Oct 2004 23:50:47 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 431AE4F50F; Mon, 18 Oct 2004 02:50:45 -0400 (EDT) Message-Id: <6.0.0.20.2.20041018154322.04cdb6f8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Oct 2004 15:46:38 +0900 To: Paul Hoffman / IMC , Antone Roundy , atom-syntax@imc.org From: Martin Duerst Subject: Re: atom:link state of play In-Reply-To: References: <4CEEB034-1D90-11D9-A16E-003065EA6144@geckotribe.com> Mime-Version: 1.0 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 At 12:48 04/10/14, Paul Hoffman / IMC wrote: > >At 9:18 PM -0600 10/13/04, Antone Roundy wrote: >>One more thing--there's an argument for not setting the bar too high: if it is too difficult to get new values officially recognized, we run the risk of people making up new values without going through the process. For this reason, it may be best to devise a mechanism that ensures (as much as possible) that we don't get naming collisions. What a dilemma. > >It's one we fight with in the IETF all the time. A standards-track RFC is probably a reasonable bar because the extension has to come up with a clear description of what you are supposed to do with the link; that kind of description easily fits into a standards-track RFC. I think of these like ESMTP extensions, of which there are many. I agree with Antone. I think a standards-track RFC is a good thing for an ESMTP extension, because extensions to a protocol need quite careful review. The link types are much less critical for interoperability, and therefore a much simpler registration should be okay. A similar move to simplify registration is also underway for URI schemes, which are again much more central to interoperability than link types. One pattern that can be seen extremely often is that there is an outside body defining a value. Sadly but truely enough, most such bodies have difficulties understanding the fact that just specifying a value in their own spec is not enough. The easier we make it for them to register, the better we achieve our main goal, namely to avoid collisions. Regards, Martin. From owner-atom-syntax@mail.imc.org Mon Oct 18 04:22: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 EAA26675 for ; Mon, 18 Oct 2004 04:22:13 -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 i9I8A9CM015882; Mon, 18 Oct 2004 01:10:09 -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 i9I8A9va015880; Mon, 18 Oct 2004 01:10:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I8A7nM015689 for ; Mon, 18 Oct 2004 01:10:08 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 18 Oct 2004 18:08:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 18 Oct 2004 18:08:38 +1000 Subject: Re: atom:link state of play From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9I8A8nM015874 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 18/10/04 10:19 AM, "Asbjørn Ulsberg" wrote: >> Specifically: "alternate", "about", and "attachment". > > Why can't we use words already known and used in Dublin Core? Or is Dublin > Core to be considered as an extension to Atom whereas Atom _needs_ to make > up its own named semantic in all places? I'm asking because I'm wondering. > > If we were to used Dublin Core's relational names here, 'hasFormat'[1], > 'hasPart'[2], 'hasVersion'[3], 'isFormatOf'[4], 'isPartOf'[5], > 'isReferencedBy'[6], 'isReplacedBy'[7], 'isRequiredBy'[8] and > 'isVersionOf'[9] are all values we could adopt directly. 'alternate' could be either 'hasFormat' or 'isFormatOf', depending on the chain of events and provenance that lead to the instantiation of the atom entry. Do we need that distinction? The (contentious) relationship denoted by 'attachment' could possibly be represented by 'requires' (which you left off your list [10]), or by 'hasPart'. Neither are entirely satisfactory matches for the use case of a long review with attachment. There is no DC equivalent of 'about' that I can see. Since we'll have to conflate a couple of distinctions, plus add in at least one term of our own, I'm not comfortable with folding in the DC terms. It'll cause implementation problems when people don't read the spec (instead taking their cues from the existence of DC terms in Atom feeds), and might be problematic for the DC camp too. We'd likely need a core set of terms, and then allow the extensibility of other terms (by whichever mechanism we finally decide on). Inevitably there will be overlaps between different extension sets and even with the core. DC has also been developed with an understanding of existing in shared spaces, playing nicely with others. In HTML for example, they don't just lump "isFormatOf" into the @rel of , they use "DCTERMS.isFormatOf", sharing that attribute space with other meta-data players (such as A-Core, AGLS, and others). I don't think they'd be mighty perturbed to do the same here. e. [1] http://dublincore.org/documents/dcmi-terms/#hasFormat [2] http://dublincore.org/documents/dcmi-terms/#hasPart [3] http://dublincore.org/documents/dcmi-terms/#hasVersion [4] http://dublincore.org/documents/dcmi-terms/#isFormatOf [5] http://dublincore.org/documents/dcmi-terms/#isPartOf [6] http://dublincore.org/documents/dcmi-terms/#isReferencedBy [7] http://dublincore.org/documents/dcmi-terms/#isReplacedBy [8] http://dublincore.org/documents/dcmi-terms/#isRequiredBy [9] http://dublincore.org/documents/dcmi-terms/#isVersionOf [10] http://dublincore.org/documents/dcmi-terms/#requires From owner-atom-syntax@mail.imc.org Mon Oct 18 12:18:19 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 MAA28697 for ; Mon, 18 Oct 2004 12:18: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 i9IG2xrF049503; Mon, 18 Oct 2004 09:02:59 -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 i9IG2xm8049497; Mon, 18 Oct 2004 09:02:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG2wY1049465 for ; Mon, 18 Oct 2004 09:02:59 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9IFRxJ6009391; Mon, 18 Oct 2004 16:28:05 +0100 (BST) In-Reply-To: <4171620F.80806@franklinmint.fm> References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <416BEA43.2090104@intertwingly.net> <4171620F.80806@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--453004390; protocol="application/pkcs7-signature" Message-Id: <4B2F53CC-211A-11D9-B075-000A2797ECDA@mac.com> Cc: Sam Ruby , Atom-Syntax From: Graham Subject: Re: Separating Link Concerns Date: Mon, 18 Oct 2004 16:27:57 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3--453004390 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 16 Oct 2004, at 7:01 pm, Robert Sayre wrote: > ... > ... > ... > > > > [undefined child content] > > > ... > +1 to the grouping syntax as a way to appease general purpose linking fans. I'm not sure about the child content issue though - I'd think the URL or the title should always go in there? Also, the atom:href syntax is redundant now - shouldn't it be dropped? Graham --Apple-Mail-3--453004390 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE4MTUyNzU4WjAjBgkqhkiG9w0BCQQxFgQUpqu28XPQn45xrUw+b3kCqkLG tcAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAllYVi8PrkBYFhFEJ/9P9dG2F aXD5lA1nRXZqPJvOQ9CpeYt7KbSqbALno3i2kKkhqu7lURho0cOQCyZLCwsJ5PW9MesolrpJ4dUF HQVaJ8Nn3EeeBkXjcIe/zd+QIvu1XXB1qxXRwhrUjaOpQzs37oVIkN/hZrpmrkn4KJ7gwmMFbx4N pEcw+ZKZkuocXllySEeYbm3ZOK4wCefFWo/R9fiEJmlTrTfyW5cY1i0KD+F2wx2K7hspjxME1hbo sgP4Kqn/z2Y+I+5qM4EysneXQZd7Tzk5Gg9vKz1bqB/KAbujGfP9r/58nhwWso4gHerrKw26f1mD vhay29APnQxdiAAAAAAAAA== --Apple-Mail-3--453004390-- From owner-atom-syntax@mail.imc.org Mon Oct 18 13:03: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 NAA01991 for ; Mon, 18 Oct 2004 13:03:05 -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 i9IGua7T059917; Mon, 18 Oct 2004 09:56:36 -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 i9IGuaJm059916; Mon, 18 Oct 2004 09:56:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postal.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGuZEo059881 for ; Mon, 18 Oct 2004 09:56:35 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id D9851AF for ; Mon, 18 Oct 2004 09:56:31 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9IGuVhc022528 for ; Mon, 18 Oct 2004 09:56:31 -0700 (PDT) Date: Mon, 18 Oct 2004 10:01:03 -0700 From: Walter Underwood To: Atom-Syntax Subject: Re: atom:link state of play Message-ID: <594C047010E742CBC35D049E@diva.verity.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9IGuZEo059902 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit --On Monday, October 18, 2004 02:19:27 AM +0200 Asbjørn Ulsberg wrote: > Why can't we use words already known and used in Dublin Core? For applications which handle blogs and other content tobether (like search engines), using Dublin Core really helps. If we define new terms, we will either have ad hoc mappings to Dublin Core or one more standard to make a recommended mapping. In the library world, a mapping between metadata schemas is called a "metadata crosswalk". Search for that if you want to see some. They are a lot of work. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Oct 18 13:15:13 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 NAA02983 for ; Mon, 18 Oct 2004 13:15:12 -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 i9IH7EBW062002; Mon, 18 Oct 2004 10:07:14 -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 i9IH7EDe062001; Mon, 18 Oct 2004 10:07:14 -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 i9IH7Dm8061944 for ; Mon, 18 Oct 2004 10:07:13 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2B8287C1EE for ; Mon, 18 Oct 2004 19:05:10 +0200 (CEST) Date: Mon, 18 Oct 2004 19:10:45 +0200 To: Atom-Syntax Subject: Time to add advertising to Atom? 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: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit «RSS Feeds Hunger for More Ads»: Is this a demand Atom should meet? How can we meet it? Any (new) thoughts? I know it has been brought up before, but as it is a more apparent need now than six months ago, people might have another view on things. Either way, time has passed and people have maybe thought more about the matter. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Oct 18 14:24: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 OAA09208 for ; Mon, 18 Oct 2004 14:24: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 i9IIBJDw075218; Mon, 18 Oct 2004 11:11: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 i9IIBJkB075217; Mon, 18 Oct 2004 11:11: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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IIBFnO075198; Mon, 18 Oct 2004 11:11:16 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Mon, 18 Oct 2004 11:11:16 -0700 To: =?iso-8859-1?Q?Asbj=F8rn?= Ulsberg , Atom-Syntax From: Paul Hoffman / IMC Subject: Re: Time to add advertising to Atom? 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 At 7:10 PM +0200 10/18/04, Asbjørn Ulsberg wrote: >Is this a demand Atom should meet? How can we meet it? With an extension. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Oct 18 15:06:27 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 PAA13621 for ; Mon, 18 Oct 2004 15:06:26 -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 i9IIteTv083582; Mon, 18 Oct 2004 11:55: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 i9IIteFP083581; Mon, 18 Oct 2004 11:55:40 -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 i9IItdNG083555; Mon, 18 Oct 2004 11:55:39 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 279B37C1EE; Mon, 18 Oct 2004 20:53:43 +0200 (CEST) Date: Mon, 18 Oct 2004 20:59:19 +0200 To: "Paul Hoffman / IMC" Subject: Re: Time to add advertising to Atom? References: 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: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 18 Oct 2004 11:11:16 -0700, Paul Hoffman / IMC wrote: >> Is this a demand Atom should meet? How can we meet it? > > With an extension. So we should just start working on that, then, right? Isn't this a good place to do it? Any ideas on how such an extension should look like? And how should it be implemented to be certain that clients will support it? I mean, if most clients don't support this extension, the ad agencies will clutter and destroy Atom (and RSS before that) with their own additions that indubitably _will_ be supported by as good as all clients. They won't hear about optional extensions supported by 5% of the client mass and in that group, everyone can turn it off whenever they want. I guess we have to think a bit broader about the problem, possibly with some protocol mechanism at work that sends messages over the wire telling the originating server that advertisement X has been read by user Y. What consequence such an action should have is in the blue, but it could be that 10 new messages are downloadable from the server. I hope the dilemma is understood. An opt-in ad extension won't be accepted as a solution. We all have to look at this problem seriously and try to find a solution that works for implementors in both ends as well as the users. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Oct 18 15:10:09 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 PAA14052 for ; Mon, 18 Oct 2004 15:10:08 -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 i9IIugsm083784; Mon, 18 Oct 2004 11:56: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 i9IIugbN083783; Mon, 18 Oct 2004 11:56:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IIufVV083758; Mon, 18 Oct 2004 11:56:41 -0700 (PDT) (envelope-from jasnell@us.ibm.com) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9IIudJ8010082; Mon, 18 Oct 2004 14:56:40 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9IIudQu325778; Mon, 18 Oct 2004 12:56:39 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9IIudKV025257; Mon, 18 Oct 2004 12:56:39 -0600 Received: from d03nm122.boulder.ibm.com (d03nm122.boulder.ibm.com [9.17.195.148]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9IIucLf025244; Mon, 18 Oct 2004 12:56:38 -0600 In-Reply-To: To: Paul Hoffman / IMC Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom-Syntax , owner-atom-syntax@mail.imc.org MIME-Version: 1.0 Subject: Re: Time to add advertising to Atom? X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: James M Snell X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 11:56:23 AM, Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 11:56:23 AM, Serialize complete at 10/18/2004 11:56:24 AM, Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 11:56:24 AM, S/MIME Sign complete at 10/18/2004 11:56:24 AM, S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 11:56:35 AM, S/MIME Sign complete at 10/18/2004 11:56:35 AM, Serialize by Router on D03NM122/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 10/18/2004 12:56:37, Serialize complete at 10/18/2004 12:56:37 Message-ID: Date: Mon, 18 Oct 2004 12:56:34 -0600 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z48741_boundary_sign Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an S/MIME signed message. ---------z48741_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 00680A3988256F31_=" This is a multipart message in MIME format. --=_alternative 00680A3988256F31_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Just to stick my nose in this a little... it may seem counter-intuitive,=20 but advertisements in feeds should be as unobtrusive as possible. First=20 off, publishers who wish to include advertisements need to decide whether=20 or not the display of the advertisements is a required part of the=20 fair-use-guidelines for their feeds. If display of advertisements is=20 required, aggregators and other applications should do the Right Thing and = ensure that advertisements are displayed. If display of ads is not=20 required, aggregators/etc should do the Right Thing and allow their users=20 to determine whether or not to display the ads. Second, ads can either be = included in or referenced by the feed. If included, some form of content=20 item extension should be used as opposed to including the ad in the main=20 content of entry. If referenced, the Atom link mechanism can be used. To = me, an ads extension that follows these characteristics makes a lot of=20 sense. There should not be anything, however, built into Atom for=20 handling advertisements. - James M Snell jasnell@us.ibm.com http://www.ibm.com (877) 511-5082 / Office 930-1979 / Tie Line Paul Hoffman / IMC =20 Sent by: owner-atom-syntax@mail.imc.org 10/18/2004 11:11 AM To Asbj=F8rn Ulsberg , Atom-Syntax=20 cc Subject Re: Time to add advertising to Atom? At 7:10 PM +0200 10/18/04, Asbj=F8rn Ulsberg wrote: >Is this a demand Atom should meet? How can we meet it? With an extension. --Paul Hoffman, Director --Internet Mail Consortium --=_alternative 00680A3988256F31_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Just to stick my nose in this a litt= le... it may seem counter-intuitive, but advertisements in feeds should be as unobtrusive as possible.  First off, publishers who wish to include advertisements need to decide whether or not the display of the advertiseme= nts is a required part of the fair-use-guidelines for their feeds.  If display of advertisements is required, aggregators and other applications should do the Right Thing and ensure that advertisements are displayed.  If display of ads is not required, aggregators/etc should do the Right Thing and allow their users to determine whether or not to display the ads.  Second, ads can either be included in or referenced by the feed.  If included, some form of content item extension should be used as opposed to including the ad in the main content of entry.  If referenced, the Atom link mechanism can be used.  To me, an ads extens= ion that follows these characteristics makes a lot of sense.  There should not be anything, however, built into Atom for handling advertisements.

- James M Snell
 jasnell@us.ibm.com
 http://www.ibm.com
 (877) 511-5082 / Office
 930-1979 / Tie Line


Paul Hoffman / IMC &l= t;phoffman@imc.org>
Sent by: owner-atom-syntax@mail.imc.= org

10/18/2004 11:11 AM

To
Asbj=F8rn Ulsberg <a= sbjorn@tigerstaden.no>, Atom-Syntax <atom-syntax@imc.org>
cc
Subject
Re: Time to add adverti= sing to Atom?






At 7:10 PM +0200 10/18/04, Asbj=F8rn Ulsberg wrote:
>Is this a demand Atom should meet? How can we meet it?

With an extension.

--Paul Hoffman, Director
--Internet Mail Consortium
--=_alternative 00680A3988256F31_=-- ---------z48741_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1 aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117 ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r 1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0 MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn 00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9 23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg /Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY 8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTAxODE4NTYyNFowIwYJKoZIhvcNAQkEMRYE FBu61XyV8zkkq/nY282NWORtWXcVMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAlg5MYMij rcfVU9Gz/JP/aGOcBqX8kBMC89qMzTv070yVL+RsJLYaFjnysQjP2aXiuoeFlrxKqIbk/+YsVQBq io68Kv6tFB6NVJX4vlmI3olq6XX/0/+haLa4bRY3de8zEkGI41QhWbZCyoru3eSt/aazT5d5gQj4 kOOUkbaaVWEAAAAA ---------z48741_boundary_sign-- From owner-atom-syntax@mail.imc.org Mon Oct 18 15:29: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 PAA16110 for ; Mon, 18 Oct 2004 15:29: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 i9IJH8qY088386; Mon, 18 Oct 2004 12:17: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 i9IJH8gX088385; Mon, 18 Oct 2004 12:17:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IJH803088360 for ; Mon, 18 Oct 2004 12:17:08 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041018191706.54785.qmail@web41203.mail.yahoo.com> Received: from [131.107.71.225] by web41203.mail.yahoo.com via HTTP; Mon, 18 Oct 2004 12:17:06 PDT Date: Mon, 18 Oct 2004 12:17:06 -0700 (PDT) From: Dare Obasanjo Subject: Re: Time to add advertising to Atom? To: "Asbjørn" Ulsberg , Paul Hoffman / IMC Cc: Atom-Syntax In-Reply-To: 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: --- Asbjørn Ulsberg wrote: > > I mean, if most clients don't support this > extension, the ad agencies will > clutter and destroy Atom (and RSS before that) with > their own additions > that indubitably _will_ be supported by as good as > all clients. They won't > hear about optional extensions supported by 5% of > the client mass and in > that group, everyone can turn it off whenever they > want. Why would any client want to explicitly support a mechanism for shoving ads in users faces regardless of whether it is in an extension or a 'mandatory' part of Atom? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Oct 18 15:35:50 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 PAA16628 for ; Mon, 18 Oct 2004 15:35:49 -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 i9IJNh0k089401; Mon, 18 Oct 2004 12:23:43 -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 i9IJNhtM089400; Mon, 18 Oct 2004 12:23:43 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IJNe2J089383; Mon, 18 Oct 2004 12:23:40 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Mon, 18 Oct 2004 12:23:41 -0700 To: =?iso-8859-1?Q?Asbj=F8rn?= Ulsberg From: Paul Hoffman / IMC Subject: Re: Time to add advertising to Atom? Cc: Atom-Syntax 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 At 8:59 PM +0200 10/18/04, Asbjørn Ulsberg wrote: >On Mon, 18 Oct 2004 11:11:16 -0700, Paul Hoffman / IMC > wrote: > >>>Is this a demand Atom should meet? How can we meet it? >> >>With an extension. > >So we should just start working on that, then, right? Wrong. An individual or a group of individuals should start work off-list, publish an Internet Draft, and bring that to the list. > Isn't this a good place to do it? To discuss proposals: yes. To start them with lots of talk: no. > Any ideas on how such an extension should look like? And how should >it be implemented to be certain that clients will support it? No and no. That's for people who are expert in the field. >I mean, if most clients don't support this extension, the ad >agencies will clutter and destroy Atom (and RSS before that) with >their own additions that indubitably _will_ be supported by as good >as all clients. They won't hear about optional extensions supported >by 5% of the client mass and in that group, everyone can turn it off >whenever they want. Such dire predictions have not been borne out in the past. "Clutter and destroy" seems a bit over the top. And, if an advertiser comes up with an extension that works so well that many client developers want to use it, what's wrong with that? Do you really think that the only extensions to Atom should come from this WG, even after we close down (hopefully next year)? >I guess we have to think a bit broader about the problem, possibly >with some protocol mechanism at work that sends messages over the >wire telling the originating server that advertisement X has been >read by user Y. What consequence such an action should have is in >the blue, but it could be that 10 new messages are downloadable from >the server. No, "we" don't. You can if you want. If after all that thinking you come up with a worked-out extension, feel free to publish it as an individual draft and alert the mailing list of its existence. >I hope the dilemma is understood. An opt-in ad extension won't be >accepted as a solution. This firm prediction is at odds with the adoption history of numerous other IETF protocols with extension mechanisms. > We all have to look at this problem seriously and try to find a >solution that works for implementors in both ends as well as the >users. I look forward to your worked-out extension as an Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Oct 18 15:49:44 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 PAA17441 for ; Mon, 18 Oct 2004 15:49: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 i9IJcKb8092423; Mon, 18 Oct 2004 12:38: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 i9IJcKsl092422; Mon, 18 Oct 2004 12:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IJcJEe092416 for ; Mon, 18 Oct 2004 12:38:19 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9IJcNNH021115 for ; Mon, 18 Oct 2004 13:38:23 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5S00KTQP7ZCF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 18 Oct 2004 13:38:23 -0600 (MDT) Received: from [192.168.1.5] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5S00F98P7Y8N@mail.sun.net> for atom-syntax@imc.org; Mon, 18 Oct 2004 13:38:23 -0600 (MDT) Date: Mon, 18 Oct 2004 12:38:48 -0700 From: Tim Bray Subject: Work Queue Rotation #11 To: Atom Syntax Cc: Joe Gregorio , Robert Sayre , Mark Nottingham Message-id: <551CE74C-213D-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT These are my takes based on watch the list and talking to Paul & Sam, occasional errors are inevitable and need to be pointed out. Public issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList PaceDateOfSubject: This has 8 listed supporters. There were two -1's in the WG, Hoehrmann (http://imc.org/atom-syntax/mail-archive/msg10355.html) on the grounds that it's not sufficiently generic, and Roundy (http://imc.org/atom-syntax/mail-archive/msg10405.html) on the basis that this should be left to an extension. However, note that neither are opposed to the concept. I think this almost but not quite qualifies as "rough" consensus, so back on the revisit queue with it. Those who want this need either to buy into an extension framework or convince the opposition. PaceLinkTitle: It certainly didn't get consensus this time around, strong -1 from Sayre (http://imc.org/atom-syntax/mail-archive/msg10410.html) and requests for changes from Roundy (http://imc.org/atom-syntax/mail-archive/msg10403.html). Let's put it back in Revisit, if someone wants to redraft it to address the concerns go ahead, if it fails to pass next time around it's dead. PaceMoveLinkElement: [Hey, he's cheating! That's not on to-discuss!] Um, even though this wasn't on our list, it got proposed and got some favorable comment and no -1's, and if we adopted it, this would make our editors' lives easier. It's even arguable that's in the domain of editorial judgement, not policy. So let's mark this accepted and do that spec-to-spec transplant. PaceLinkAttrDefaults, PaceLinkConstruct, PaceLinkDelicious, PaceLinkParent, PaceLinkPurpose, PaceLinkRelMechanism, PaceReplaceLinkElement As I pointed out earlier (http://imc.org/atom-syntax/mail-archive/msg10570.html), we lack consensus on multiple axes. However, having revisited the discussion and talked with Paul/Sam, I'm going to reverse my position on PaceLinkAttrDefaults. While it got some -1's (http://imc.org/atom-syntax/mail-archive/msg10432.html, http://imc.org/atom-syntax/mail-archive/msg10400.html, http://imc.org/atom-syntax/mail-archive/msg10382.html), they were mostly "This goes too far". Which may be correct, but where it goes is precisely to the minimum point of consensus. I believe we *do* have good-enough consensus that there should be a and also on rel="related". We do *not* have consensus as to what, if any, other values should be allowed, and we do *not* have consensus on what extension mechanism, if any, should be provided for the value space. But, we also do not have consensus support for the values currently listed in the draft. So, I'm going to call for PaceLinkAttrDefaults to be accepted; rolling this into the spec will in fact reflect the minimum shared understanding better than what's there now. As for all the other Paces, PaceLinkRelMechanism is closed and the rest go back on the Revisit queue. Following that, I'm going to launch a general discussion on link extensibility, whether and how, to see if we can get consensus on basics, which should allow us to discard most of these Paces and build something people can buy into. -Tim From owner-atom-syntax@mail.imc.org Mon Oct 18 15:57: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 PAA17972 for ; Mon, 18 Oct 2004 15:57: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 i9IJm3ka094097; Mon, 18 Oct 2004 12:48:03 -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 i9IJm3Oj094096; Mon, 18 Oct 2004 12:48:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IJlv5v094052 for ; Mon, 18 Oct 2004 12:48:03 -0700 (PDT) (envelope-from jarober@gosmalltalk.com) Received: from victoria (pcp01741172pcs.howard01.md.comcast.net[68.54.83.139]) by comcast.net (rwcrmhc13) with ESMTP id <2004101819475301500n3ue8e>; Mon, 18 Oct 2004 19:47:53 +0000 Received: from james2.gosmalltalk.com ([10.55.1.101]) by victoria (8.11.0/8.11.0) with ESMTP id i9IJlqA31521 for ; Mon, 18 Oct 2004 15:47:52 -0400 Message-Id: <6.1.2.0.2.20041018154549.02d04ec0@www.gosmalltalk.com> X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Oct 2004 15:47:48 -0400 To: atom-syntax@imc.org From: James Robertson Subject: Re: Time to add advertising to Atom? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9IJm35v094091 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Here's a really wild thought - each item could be an ad, using either markup or plain text as the provider saw fit. Which means that it's already supported. If providers overdo it, then subscribers will opt out. Why is this hard? At 03:23 PM 10/18/2004, you wrote: >At 8:59 PM +0200 10/18/04, Asbjørn Ulsberg wrote: >>On Mon, 18 Oct 2004 11:11:16 -0700, Paul Hoffman / IMC >>wrote: >> >>>>Is this a demand Atom should meet? How can we meet it? >>> >>>With an extension. >> >>So we should just start working on that, then, right? > >Wrong. An individual or a group of individuals should start work off-list, >publish an Internet Draft, and bring that to the list. > >> Isn't this a good place to do it? > >To discuss proposals: yes. To start them with lots of talk: no. > >> Any ideas on how such an extension should look like? And how should it >> be implemented to be certain that clients will support it? > >No and no. That's for people who are expert in the field. > >>I mean, if most clients don't support this extension, the ad agencies >>will clutter and destroy Atom (and RSS before that) with their own >>additions that indubitably _will_ be supported by as good as all clients. >>They won't hear about optional extensions supported by 5% of the client >>mass and in that group, everyone can turn it off whenever they want. > >Such dire predictions have not been borne out in the past. "Clutter and >destroy" seems a bit over the top. And, if an advertiser comes up with an >extension that works so well that many client developers want to use it, >what's wrong with that? Do you really think that the only extensions to >Atom should come from this WG, even after we close down (hopefully next year)? > >>I guess we have to think a bit broader about the problem, possibly with >>some protocol mechanism at work that sends messages over the wire telling >>the originating server that advertisement X has been read by user Y. What >>consequence such an action should have is in the blue, but it could be >>that 10 new messages are downloadable from the server. > >No, "we" don't. You can if you want. If after all that thinking you come >up with a worked-out extension, feel free to publish it as an individual >draft and alert the mailing list of its existence. > >>I hope the dilemma is understood. An opt-in ad extension won't be >>accepted as a solution. > >This firm prediction is at odds with the adoption history of numerous >other IETF protocols with extension mechanisms. > >> We all have to look at this problem seriously and try to find a >> solution that works for implementors in both ends as well as the users. > >I look forward to your worked-out extension as an Internet Draft. > >--Paul Hoffman, Director >--Internet Mail Consortium > > James Robertson, Product Manager, Cincom Smalltalk http://www.cincomsmalltalk.com/blog/blogView jarober@gosmalltalk.com From owner-atom-syntax@mail.imc.org Mon Oct 18 16:27:57 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 QAA20311 for ; Mon, 18 Oct 2004 16:27:56 -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 i9IKIxxc098851; Mon, 18 Oct 2004 13:18:59 -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 i9IKIxOu098850; Mon, 18 Oct 2004 13:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IKIw83098841 for ; Mon, 18 Oct 2004 13:18:58 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9IKJ2ui023649 for ; Mon, 18 Oct 2004 14:19:02 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5S00KECR3P6I@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 18 Oct 2004 14:19:01 -0600 (MDT) Received: from [192.168.1.5] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5S00KJ4R3OS9@mail.sun.net> for atom-syntax@imc.org; Mon, 18 Oct 2004 14:19:01 -0600 (MDT) Date: Mon, 18 Oct 2004 13:19:27 -0700 From: Tim Bray Subject: Re: Time to add advertising to Atom? In-reply-to: <6.1.2.0.2.20041018154549.02d04ec0@www.gosmalltalk.com> To: James Robertson Cc: atom-syntax@imc.org Message-id: <02AE2AA4-2143-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6.1.2.0.2.20041018154549.02d04ec0@www.gosmalltalk.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 18, 2004, at 12:47 PM, James Robertson wrote: > > Here's a really wild thought - each item could be an ad, using either > markup or plain text as the provider saw fit. Which means that it's > already supported. If providers overdo it, then subscribers will opt > out. Why is this hard? In fact this is being done today. It seems to work. -Tim From owner-atom-syntax@mail.imc.org Mon Oct 18 16:40: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 QAA21084 for ; Mon, 18 Oct 2004 16:40: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 i9IKXJJe001015; Mon, 18 Oct 2004 13:33: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 i9IKXJFi001014; Mon, 18 Oct 2004 13:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IKXIjd001005 for ; Mon, 18 Oct 2004 13:33:18 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9IKXMui001342 for ; Mon, 18 Oct 2004 14:33:22 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5S00K2DRRM6I@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 18 Oct 2004 14:33:22 -0600 (MDT) Received: from [192.168.1.5] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5S00KKKRRLST@mail.sun.net> for atom-syntax@imc.org; Mon, 18 Oct 2004 14:33:22 -0600 (MDT) Date: Mon, 18 Oct 2004 13:33:48 -0700 From: Tim Bray Subject: Options for link extensibility To: Atom Syntax Message-id: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Our discussion has turned up four basic strategies for link extensibility. I think that before we argue any more about atom:link syntax, we need to have consensus at the meta level, or prove that we're not going to get consensus. How to do link extensibility: LE0 Don't: Atom has no abstract notion of a link. LE1 Hardwired: Itemize the different kinds of links in the Atom specification. Extensibility requires a new version of the Atom specification. LE2 Registry: The types of links are in a (presumably IANA) registry, which can be extended using a well-understood process. LE3 URIs: Non-centralized extensibility is achieved by using URIs to name types of links. Note that these do not involve syntax arguments. If we manage to converge on one of these, then we argue about the syntax (e.g. for LE4, qnames or full URIs), but that's a much more focused discussion than we've managed to have so far. If people think it's a good idea, we could run a -1/0/+1 survey on the wiki (I'd be "0" on all four). If people want to speak up and argue that one of these options is substantially better than all the others, that would be appropriate: please include LE0, LE1, LE2, or LE3 in your subject line. If such an argument gets a lot of support and little opposition, we can discard a bunch of the Paces and move to focus on the syntax. My sense of the group is that LE2 is perhaps slightly more likely than any other alternative to gain consensus, but I could very easily be wrong. -Tim From owner-atom-syntax@mail.imc.org Mon Oct 18 16:56: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 QAA22544 for ; Mon, 18 Oct 2004 16:56: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 i9IKfrlX002419; Mon, 18 Oct 2004 13: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 i9IKfrl8002418; Mon, 18 Oct 2004 13:41:53 -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 i9IKfrTi002403 for ; Mon, 18 Oct 2004 13:41:53 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CJeKF-0000Vp-4K; Mon, 18 Oct 2004 20:41:51 +0000 Message-ID: <41742A85.5030601@franklinmint.fm> Date: Mon, 18 Oct 2004 16:41:41 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Options for link extensibility References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > LE2 Registry: The types of links are in a (presumably IANA) registry, > which can be extended using a well-understood process. > > LE3 URIs: Non-centralized extensibility is achieved by using URIs to > name types of links. > > > My sense of the group is that LE2 is perhaps slightly more likely than > any other alternative to gain consensus, but I could very easily be wrong. Could Paul or anyone else versed in IANA registration of such things outline the general procedure for doing so? What does an author have to do before unleashing a new link type on the wild? Is it realistic to expect that they will actually do it? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 18 17: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 RAA23379 for ; Mon, 18 Oct 2004 17:09:34 -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 i9IL1QTP005570; Mon, 18 Oct 2004 14:01:26 -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 i9IL1QEY005569; Mon, 18 Oct 2004 14:01:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IL1QLJ005548; Mon, 18 Oct 2004 14:01:26 -0700 (PDT) (envelope-from jasnell@us.ibm.com) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9IL1PJ8111994; Mon, 18 Oct 2004 17:01:25 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9IL1NqL147698; Mon, 18 Oct 2004 15:01:24 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9IL1NR2003222; Mon, 18 Oct 2004 15:01:23 -0600 Received: from d03nm122.boulder.ibm.com (d03nm122.boulder.ibm.com [9.17.195.148]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9IL1J6q003015; Mon, 18 Oct 2004 15:01:19 -0600 In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> To: Tim Bray Cc: Atom Syntax , owner-atom-syntax@mail.imc.org MIME-Version: 1.0 Subject: Re: Options for link extensibility X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: James M Snell X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 01:54:27 PM, Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 01:54:27 PM, Serialize complete at 10/18/2004 01:54:27 PM, Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 01:54:28 PM, S/MIME Sign complete at 10/18/2004 01:54:28 PM, S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September 26, 2003) at 10/18/2004 02:01:18 PM, S/MIME Sign complete at 10/18/2004 02:01:18 PM, Serialize by Router on D03NM122/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 10/18/2004 15:01:19, Serialize complete at 10/18/2004 15:01:19 Message-ID: Date: Mon, 18 Oct 2004 15:01:17 -0600 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z10059_boundary_sign Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an S/MIME signed message. ---------z10059_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0072D93C88256F31_=" This is a multipart message in MIME format. --=_alternative 0072D93C88256F31_= Content-Type: text/plain; charset="US-ASCII" >LE2 Registry: The types of links are in a (presumably IANA) registry, >which can be extended using a well-understood process. >LE3 URIs: Non-centralized extensibility is achieved by using URIs to >name types of links. Would a union of these two options make sense? A core set of known and well-understood link types managed by IANA with extension types identified using URI? - James M Snell jasnell@us.ibm.com http://www.ibm.com (877) 511-5082 / Office 930-1979 / Tie Line Tim Bray Sent by: owner-atom-syntax@mail.imc.org 10/18/2004 01:33 PM To Atom Syntax cc Subject Options for link extensibility Our discussion has turned up four basic strategies for link extensibility. I think that before we argue any more about atom:link syntax, we need to have consensus at the meta level, or prove that we're not going to get consensus. How to do link extensibility: LE0 Don't: Atom has no abstract notion of a link. LE1 Hardwired: Itemize the different kinds of links in the Atom specification. Extensibility requires a new version of the Atom specification. LE2 Registry: The types of links are in a (presumably IANA) registry, which can be extended using a well-understood process. LE3 URIs: Non-centralized extensibility is achieved by using URIs to name types of links. Note that these do not involve syntax arguments. If we manage to converge on one of these, then we argue about the syntax (e.g. for LE4, qnames or full URIs), but that's a much more focused discussion than we've managed to have so far. If people think it's a good idea, we could run a -1/0/+1 survey on the wiki (I'd be "0" on all four). If people want to speak up and argue that one of these options is substantially better than all the others, that would be appropriate: please include LE0, LE1, LE2, or LE3 in your subject line. If such an argument gets a lot of support and little opposition, we can discard a bunch of the Paces and move to focus on the syntax. My sense of the group is that LE2 is perhaps slightly more likely than any other alternative to gain consensus, but I could very easily be wrong. -Tim --=_alternative 0072D93C88256F31_= Content-Type: text/html; charset="US-ASCII"
>LE2 Registry:  The types of links are in a (presumably IANA) registry,
>which can be extended using a well-understood process.

>LE3 URIs:  Non-centralized extensibility is achieved by using URIs to
>name types of links.

Would a union of these two options make sense?  A core set of known and well-understood link types managed by IANA with extension types identified using URI?

- James M Snell
 jasnell@us.ibm.com
 http://www.ibm.com
 (877) 511-5082 / Office
 930-1979 / Tie Line


Tim Bray <Tim.Bray@Sun.COM>
Sent by: owner-atom-syntax@mail.imc.org

10/18/2004 01:33 PM

To
Atom Syntax <atom-syntax@imc.org>
cc
Subject
Options for link extensibility






Our discussion has turned up four basic strategies for link
extensibility.  I think that before we argue any more about atom:link
syntax, we need to have consensus at the meta level, or prove that
we're not going to get consensus.

How to do link extensibility:

LE0 Don't:  Atom has no abstract notion of a link.

LE1 Hardwired:  Itemize the different kinds of links in the Atom
specification.  Extensibility requires a new version of the Atom
specification.

LE2 Registry:  The types of links are in a (presumably IANA) registry,
which can be extended using a well-understood process.

LE3 URIs:  Non-centralized extensibility is achieved by using URIs to
name types of links.

Note that these do not involve syntax arguments.  If we manage to
converge on one of these, then we argue about the syntax (e.g. for LE4,
qnames or full URIs), but that's a much more focused discussion than
we've managed to have so far.

If people think it's a good idea, we could run a -1/0/+1 survey on the
wiki (I'd be "0" on all four). If people want to speak up and argue
that one of these options is substantially better than all the others,
that would be appropriate: please include LE0, LE1, LE2, or LE3 in your
subject line.  If such an argument gets a lot of support and little
opposition, we can discard a bunch of the Paces and move to focus on
the syntax.

My sense of the group is that LE2 is perhaps slightly more likely than
any other alternative to gain consensus, but I could very easily be
wrong.

  -Tim
--=_alternative 0072D93C88256F31_=-- ---------z10059_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1 aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117 ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r 1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0 MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf 1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn 00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9 23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg /Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY 8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MTAxODIwNTQyN1owIwYJKoZIhvcNAQkEMRYE FO+whQqYiG1Vv3s2PBUSBk5EA4atMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAqE/AdB1p E76eSTAvmRQfPMc/gIGhiXSrhdjyJiOMvK9JwTttIEyWReb75I92FRIQa8ZiP/ps/bazFWSTb7HC Tpl+r/SwSpvMV6KREMOOA8/IVpmbDYsMpGxXpgQpiMIPRrXSCD/UPWwBFcx5TFKOELY0e//uHwyB 3gtLCbdoP/QAAAAA ---------z10059_boundary_sign-- From owner-atom-syntax@mail.imc.org Mon Oct 18 17:35:13 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 RAA25584 for ; Mon, 18 Oct 2004 17:35:13 -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 i9ILO1X8009762; Mon, 18 Oct 2004 14:24:01 -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 i9ILO1LN009761; Mon, 18 Oct 2004 14:24:01 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ILNxIX009751 for ; Mon, 18 Oct 2004 14:24:00 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <41742A85.5030601@franklinmint.fm> References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> <41742A85.5030601@franklinmint.fm> Date: Mon, 18 Oct 2004 14:24:01 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Options for link extensibility 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 4:41 PM -0400 10/18/04, Robert Sayre wrote: >Could Paul or anyone else versed in IANA registration of such things >outline the general procedure for doing so? What does an author have >to do before unleashing a new link type on the wild? Is it realistic >to expect that they will actually do it? When an RFC creates an IANA registry, the RFC states how that registry will be updated. We can say whatever we want, as long as what we say can be understood by a secretarial-type person. (Currently, a very nice secretarial-type person, FWIW.) Common updating choices today are: - Must have an RFC of any sort - Must have a standards-track RFC (they're harder to get but they also have more review in the IETF) - Must have the agreement of the IESG (which often means "must have the agreement of a couple of members of the IESG who tell the other ones 'this is OK'") - Must have the agreement of an IESG-appointed "expert" (who usually has a mailing list to discuss the requests) - Only needs a message to IANA (this is now rare due to abuse) We can do whatever we want, but we'll probably have to live with the results. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 19 04:23: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 EAA00500 for ; Tue, 19 Oct 2004 04:23: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 i9J8DKdc069546; Tue, 19 Oct 2004 01:13: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 i9J8DKIb069545; Tue, 19 Oct 2004 01:13:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9J8DJ8Y069494 for ; Tue, 19 Oct 2004 01:13:19 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CJp7D-00054x-00; Tue, 19 Oct 2004 09:13:07 +0100 Date: Tue, 19 Oct 2004 09:13:07 +0100 From: James Aylett To: Atom-Syntax Subject: Re: Time to add advertising to Atom? Message-ID: <20041019081307.GB7537@tartarus.org> Mail-Followup-To: James Aylett , Atom-Syntax References: <20041018191706.54785.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041018191706.54785.qmail@web41203.mail.yahoo.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 18, 2004 at 12:17:06PM -0700, Dare Obasanjo wrote: > Why would any client want to explicitly support a > mechanism for shoving ads in users faces regardless of > whether it is in an extension or a 'mandatory' part of > Atom? Which is pretty much why most people will just put the ads in as items (as currently); all an extension would do is to mark them as advertising, which might conceivably be needed for anti-spam laws in some territories. Quite what would happen then is anyone's guess - if a significant number of aggregators just rip out marked advertising (and some will), the utility of the extension to the advertisers is pretty limited. I don't think this is something atompub should get involved in. I'm not really convinced that anyone should try to get involved in it :-) (But I don't speak for my employer here.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Tue Oct 19 07:03: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 HAA10626 for ; Tue, 19 Oct 2004 07:03: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 i9JAtKCN035376; Tue, 19 Oct 2004 03: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 i9JAtKWY035374; Tue, 19 Oct 2004 03:55:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JAtJBJ035352 for ; Tue, 19 Oct 2004 03:55:19 -0700 (PDT) (envelope-from sc@itst.net) Received: from webmail.cat-proof.de (localhost [127.0.0.1]) by cat-proof.de (Postfix) with SMTP id 3593F341038B for ; Tue, 19 Oct 2004 12:52:41 +0200 (CEST) Received: from 195.243.113.249 (SquirrelMail authenticated user sc@itst.net) by webmail.cat-proof.de with HTTP; Tue, 19 Oct 2004 12:52:41 +0200 (CEST) Message-ID: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> In-Reply-To: References: Date: Tue, 19 Oct 2004 12:52:41 +0200 (CEST) Subject: Re: Time to add advertising to Atom? From: "Sascha Carlin" To: "Atom-Syntax" Reply-To: sc@itst.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Why not implement an attribute for atom:item called ad="ad" like its done with checked="checked" within XHTML? Since advertisments must be marked being an advertisment, we could provide this attribute to help ad-publishers by giving them a standardized way of marking ads and consumers a way to doubtless identify ads. cu, Sascha From owner-atom-syntax@mail.imc.org Tue Oct 19 10:06:36 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 KAA27168 for ; Tue, 19 Oct 2004 10:06: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 i9JDtMMh072671; Tue, 19 Oct 2004 06:55:22 -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 i9JDtM5C072670; Tue, 19 Oct 2004 06:55:22 -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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JDtM7q072664 for ; Tue, 19 Oct 2004 06:55:22 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so671428rnl for ; Tue, 19 Oct 2004 06:55:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ra2FEsvRLtr9MunDy1dWcZ2KrmqmsRTBZMDEJH/uBu2iVPgPZJrCZRxwTBRhYkMVoiodoGYTmTbHrpmfLpVfS7PtJgTY0VcWdfgePSL/gpQONsnxrvd2dQd/XQf51NwFeFZ+Q8idfDjFrs74TT9N2V2rZy6cN2GyGd/3/7XyeV4 Received: by 10.38.24.12 with SMTP id 12mr1965814rnx; Tue, 19 Oct 2004 06:55:23 -0700 (PDT) Received: by 10.38.151.74 with HTTP; Tue, 19 Oct 2004 06:55:23 -0700 (PDT) Message-ID: <3f1451f504101906551d400e6c@mail.gmail.com> Date: Tue, 19 Oct 2004 09:55:23 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: Options for link extensibility Cc: Atom Syntax In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 18 Oct 2004 13:33:48 -0700, Tim Bray wrote: > > Our discussion has turned up four basic strategies for link > extensibility. I think that before we argue any more about atom:link > syntax, we need to have consensus at the meta level, or prove that > we're not going to get consensus. > > How to do link extensibility: > > LE0 Don't: Atom has no abstract notion of a link. > > LE1 Hardwired: Itemize the different kinds of links in the Atom > specification. Extensibility requires a new version of the Atom > specification. > > LE2 Registry: The types of links are in a (presumably IANA) registry, > which can be extended using a well-understood process. > > LE3 URIs: Non-centralized extensibility is achieved by using URIs to > name types of links. First, isn't it a bit backward to be talking about link extensibility before talking about general format extensibility? Modulo that bit of parlimentary shuffling, I would have to settle on LE0. Here is my reasoning: I believe that we started this group to clean up and create a solid foundation for syndication technology, a foundation that we fully expected a raft of innovations to be built upon. I think there is value in being able to let a thousand flowers bloom and letting any person with a web site propose extensions[1][2].Given that premise, I don't think LE1 or LE2 are appropriate.I believe they raise the bar too high for innovation. LE3 is a good choice if we agree there is a common abstract notion of a link, and that it is worth segregating it out. I will note however that since we can transport HTML as our content, and said HTML can contain links, and images, and SVG, and Flash, etc that an abstract link mechanism is in no way mandatory. I will also note that RSS (in all it's varieties) has survived fine w/o such a mechanism. Ahh, but what about enclosures? They are handled in RSS via general format extension and not a generic link syntax. Which, for all these reasons combined, leads me to select LE0. Thanks, -joe [1] http://wellformedweb.org/news/wfw_namespace_elements [2] http://wellformedweb.org/news/35 -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue Oct 19 10:34:59 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 KAA01454 for ; Tue, 19 Oct 2004 10:34:58 -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 i9JEQMJG077550; Tue, 19 Oct 2004 07:26:22 -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 i9JEQMNN077549; Tue, 19 Oct 2004 07:26:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JEQLHl077533 for ; Tue, 19 Oct 2004 07:26:22 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9JDLllj009984; Tue, 19 Oct 2004 14:21:52 +0100 (BST) In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--374176640; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: Options for link extensibility Date: Tue, 19 Oct 2004 14:21:47 +0100 To: Tim Bray X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2--374176640 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 18 Oct 2004, at 9:33 pm, Tim Bray wrote: > LE2 Registry: The types of links are in a (presumably IANA) registry, > which can be extended using a well-understood process. I don't like this at all. No one will use it, and it basically requires consensus in the group that the extensibility mechanism in XML is a failure, when I think it's actually dead good. > LE3 URIs: Non-centralized extensibility is achieved by using URIs to > name types of links. +1 if there's a sensible way to do it (Robert's yesterday is the only way I've seen) > If people think it's a good idea, we could run a -1/0/+1 survey on the > wiki (I'd be "0" on all four). If people want to speak up and argue > that one of these options is substantially better than all the others, > that would be appropriate: please include LE0, LE1, LE2, or LE3 in > your subject line. If such an argument gets a lot of support and > little opposition, we can discard a bunch of the Paces and move to > focus on the syntax. -1000 to a vote. I don't like the way you've set this up since my support/objection depends almost entirely to which syntax we choose. Graham --Apple-Mail-2--374176640 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE5MTMyMTQ3WjAjBgkqhkiG9w0BCQQxFgQU+A9SyKqxXXRw+OJ360X2V8Sn knkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAwjWHeBPN3IPcGQ0VMcb3r5S3 +XeSLXecTCL9F/tSBcGmMlNRpjkPkN0cna6a35UbISlAhx9nviYLu12nETMACBrsxWp0DjtWpoIG EYJalMpT9YrQmkWccGqG1C5dw7gEFn5rDBsiM4WqrOp0inhZ2L5MYaRcOSdmra6oAWN1v7EQACmi q3w8JuXLAlmnr0EhBUWRGleAHAX3MKW0qmBjeP5GVoPVWTPrIKP6PZZIhT4cb+dakeT/uh24WJlz hV5Yxl+641ZvYZopGDhRFpOADUpQaw8nDP3SME+TEDwg5ffybVsomGKmuAbXra3NGjkiOTEIrH2D TqPrT6arfSAEWwAAAAAAAA== --Apple-Mail-2--374176640-- From owner-atom-syntax@mail.imc.org Tue Oct 19 11:05:24 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 LAA04815 for ; Tue, 19 Oct 2004 11:05:23 -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 i9JEw10s082097; Tue, 19 Oct 2004 07:58:01 -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 i9JEw1Gi082096; Tue, 19 Oct 2004 07:58:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JEw0nu082079 for ; Tue, 19 Oct 2004 07:58:01 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9JDrVEh026852 for ; Tue, 19 Oct 2004 14:53:33 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) To: Atom Syntax Message-Id: <431D5204-21D6-11D9-858D-000A2797ECDA@mac.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--372272545; protocol="application/pkcs7-signature" From: Graham Subject: Proposal: PaceLinkByLocation Date: Tue, 19 Oct 2004 14:53:31 +0100 X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3--372272545 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceLinkByLocation Based on Robert Sayre's suggestion yesterday, and my own PaceReplaceLinkElement. Abstract Replace link element with individual links, but group them within a links element. That an extenstion element is a links element is then discerned from its location inside the links group. Rationale There have been many proposals allowing link extensibility while still being able to extract all links from an entry or feed. None of these do both well without some other unacceptable tradeoff. This proposal allows full and standard use of XML namespace syntax while still fulfilling the latter goal, by grouping all of the links together inside a links element. Example: ... ... Graham --Apple-Mail-3--372272545 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDE5MTM1MzMxWjAjBgkqhkiG9w0BCQQxFgQUqtyC/6jNHi/0ppdayN6y3Q5O TIYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAk9YCL1SYW5BcIbhjipGG1UxO iascuu/WWfsAAK250Zoqc1QTAkCsXgFtYLp2L1kOn/AHWPCbF73mj/XEVWNdvFbo5O7czHw9IO2h 3YPKFlyRFm4uRT1RocE3nwJ4Vs5Lw+rxY7ztSPZGQd824nwBntLfQS2LmtVLaIEV08tJ6OSUdpid 9FZEntgqscLNOwkw/H+wer6eTjsBKn5MjID6Kd4oHPu5ryPiFjq3jg/UDSCY0zHv984DoHtWSqnC UFoW+0xE16nO/kRxrp1ZiObyqqb+RAlRPzDD212FeE7EzVGBq1Cnd88doDb8xUkTy1pZaCmWCFKy RAeU0ssFBnSLzAAAAAAAAA== --Apple-Mail-3--372272545-- From owner-atom-syntax@mail.imc.org Tue Oct 19 11:23:07 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 LAA06622 for ; Tue, 19 Oct 2004 11:23: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 i9JFEpik084844; Tue, 19 Oct 2004 08:14:51 -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 i9JFEpoT084843; Tue, 19 Oct 2004 08:14:51 -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 i9JFEpTa084827 for ; Tue, 19 Oct 2004 08:14:51 -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 1CJvhI-0004ig-2K; Tue, 19 Oct 2004 15:14:48 +0000 Message-ID: <41752F68.7000508@franklinmint.fm> Date: Tue, 19 Oct 2004 11:14:48 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Tim Bray , Atom Syntax Subject: Re: Options for link extensibility References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> <3f1451f504101906551d400e6c@mail.gmail.com> In-Reply-To: <3f1451f504101906551d400e6c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > > LE3 is a good choice if we agree there is a common > abstract notion of a link, and that it is worth segregating > it out. I will note however that since we can transport HTML as our > content, and said HTML can contain links, and images, > and SVG, and Flash, etc that an abstract link mechanism > is in no way mandatory. I'll spring for LE3. Links in the payload is a non-argument. They might as well not even be there, since aggregators are free to strip whatever they see fit, and those links might live in HTML tag soup. I think the notion of Media-Independent links is valuable. The only problem with the HTML4 syntax is that it's a little looser than we want to be (unqualified, composable rel names). "A link is a connection from one Web resource to another. Although a simple concept, the link has been one of the primary forces driving the success of the Web. The default behavior associated with a link is the retrieval of another Web resource."[0] enclosure is a good example, because retrieval is still useful, even if the client doesn't understand the paperclip semantics. It's nothing new, just a way to annotate a hyperlink with additional semantics, which doesn't require a lot of infrastructure. That we have people writing rel="related" is evidence enough that we have a general idea of a link. Robert Sayre [0] http://www.w3.org/TR/REC-html40/struct/links.html From owner-atom-syntax@mail.imc.org Tue Oct 19 11:34:13 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 LAA07397 for ; Tue, 19 Oct 2004 11:34:12 -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 i9JFOK1b086341; Tue, 19 Oct 2004 08:24: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 i9JFOKDr086340; Tue, 19 Oct 2004 08:24:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JFOJs9086318 for ; Tue, 19 Oct 2004 08:24:20 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 44561 messnum 7760920 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 19 Oct 2004 15:24:16 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.25?) (62.77.172.85) by mail01.svc.cra.dublin.eircom.net (qp 44561) with SMTP; 19 Oct 2004 15:24:16 -0000 Message-ID: <4175319A.8020903@dehora.net> Date: Tue, 19 Oct 2004 16:24:10 +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: Options for link extensibility References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> 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 Tim Bray wrote: > How to do link extensibility: > > LE0 Don't: Atom has no abstract notion of a link. 0. If there is an abstraction we haven't found it yet. > LE1 Hardwired: Itemize the different kinds of links in the Atom > specification. Extensibility requires a new version of the Atom > specification. -1. Assumes we have an abstract notion of a link; see above. Also, assumes we are closed for extension and modification of link types and link operands. I'm rarely that confident about such things. Finally, closes the door on innovation and surely encourages daft workarounds for what will be obvious requirements two years from now - not much fun there. > LE2 Registry: The types of links are in a (presumably IANA) registry, > which can be extended using a well-understood process. -1. My crystal ball tells me hardly anyone will use that process - it's way too prim and bound to take the fun out of things. > LE3 URIs: Non-centralized extensibility is achieved by using URIs to > name types of links. +1. There are a number of ways to attach information to a URI. It also leaves an option for us or others to revisit this matter. I agree with Joe's position, but think a) it makes sense to leave a hook, b) we can do that without assuming an abstraction. What we'd be saying is that we suspect signaling control codes from publisher to reader might be an interesting thing to do for link-like things, but we don't know what those codes might be at the moment since we can't agree on link-likeness - go innovate. IOW: 1. leave a hook for someone to determine future mechanisms and abstractions. 2. Mandate a noop/default URI value now for that hook. 3. Don't engage the WG any further in trying to determine what the mechanisms and abstractions could be for the time being. 4. *Strictly timebox* how long we have to determine the form and nature of LE3; if we don't ship something for the editors within that time, fall back to LE0. [If we don't agree to timebox. my consensus immediately goes to LE0.] cheers Bill From owner-atom-syntax@mail.imc.org Tue Oct 19 12:00:56 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 MAA10255 for ; Tue, 19 Oct 2004 12:00:55 -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 i9JFmABt089875; Tue, 19 Oct 2004 08:48:10 -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 i9JFmAGq089874; Tue, 19 Oct 2004 08:48:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFmAw0089859 for ; Tue, 19 Oct 2004 08:48:10 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9JFlq27007241; Tue, 19 Oct 2004 11:47:59 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BVK55652 (AUTH bob@wyman.us); Tue, 19 Oct 2004 11:47:49 -0400 (EDT) Message-Id: <200410191547.BVK55652@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'James Robertson'" , Subject: RE: Time to add advertising to Atom? Date: Tue, 19 Oct 2004 11:47:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS1TYkS9xSsfKhjTl2zZt2Vuztv7gApD/eA In-Reply-To: <6.1.2.0.2.20041018154549.02d04ec0@www.gosmalltalk.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Robertson wrote: > Here's a really wild thought - each item could be an ad, using > either markup or plain text as the provider saw fit. Which means > that it's already supported. If providers overdo it, then > subscribers will opt out. Why is this hard? In many cases, what you suggest is probably quite adequate; however, I think it is important to remember that not all Atom entries will be handled as text. For instance, you might have a feed of "Airport Delay Status" or "Weather" whose entries are processed by some clients as data rather than as text. (i.e. the entries might drive some interactive map rather than a text display.). In such a feed, an advertisement for something like a "cheap airplane ticket to Florida" would probably have a different encoding then the other entries in the feed. The ad would likely be text rather than some other XML type. It would be useful, I think, for feed producers to be able to flag the ads in such feeds with some sort of metadata to indicate to the client that they require special handling. bob wyman From owner-atom-syntax@mail.imc.org Tue Oct 19 12:34:59 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 MAA13251 for ; Tue, 19 Oct 2004 12:34:57 -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 i9JGRJEH096094; Tue, 19 Oct 2004 09:27: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 i9JGRJTd096093; Tue, 19 Oct 2004 09:27:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41206.mail.yahoo.com (web41206.mail.yahoo.com [66.218.93.39]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JGRJLU096065 for ; Tue, 19 Oct 2004 09:27:19 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041019162717.88731.qmail@web41206.mail.yahoo.com> Received: from [24.18.132.123] by web41206.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 09:27:17 PDT Date: Tue, 19 Oct 2004 09:27:17 -0700 (PDT) From: Dare Obasanjo Subject: Re: Options for link extensibility To: Joe Gregorio , Tim Bray Cc: Atom Syntax In-Reply-To: <3f1451f504101906551d400e6c@mail.gmail.com> 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: --- Joe Gregorio wrote: > > First, isn't it a bit backward to be talking about > link extensibility > before talking about general format extensibility? > > Modulo that bit of parlimentary shuffling, I would > have to > settle on LE0. Here is my reasoning: > > I believe that we started this group to clean up > and create a solid foundation for syndication > technology, a > foundation that we fully expected a raft of > innovations to be > built upon. I think there is value in being able to > let a > thousand flowers bloom and letting any person with a > web > site propose extensions[1][2].Given that premise, > I don't think LE1 or LE2 are appropriate.I believe > they > raise the bar too high for innovation. > > LE3 is a good choice if we agree there is a common > abstract notion of a link, and that it is worth > segregating > it out. I will note however that since we can > transport HTML as our > content, and said HTML can contain links, and > images, > and SVG, and Flash, etc that an abstract link > mechanism > is in no way mandatory. I will also note that RSS > (in all it's > varieties) has survived fine w/o such a mechanism. > Ahh, but what about enclosures? They are handled in > RSS via > general format extension and not a generic link > syntax. > > Which, for all these reasons combined, leads me to > select LE0. +1 As I mentioned earlier, if the WG can come up with a well defined notion of what it means to be a link I'd go for LE3 otherwise I'm in the LE0 court. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 19 12:44:47 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 MAA14782 for ; Tue, 19 Oct 2004 12:44:46 -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 i9JGbxex098401; Tue, 19 Oct 2004 09:37:59 -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 i9JGbxf1098400; Tue, 19 Oct 2004 09:37:59 -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 i9JGbuqg098385 for ; Tue, 19 Oct 2004 09:37:58 -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 1CJwzi-0000i7-5B; Tue, 19 Oct 2004 16:37:54 +0000 Message-ID: <417542E3.3040603@franklinmint.fm> Date: Tue, 19 Oct 2004 12:37:55 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Joe Gregorio , Tim Bray , Atom Syntax Subject: Re: Options for link extensibility References: <20041019162717.88731.qmail@web41206.mail.yahoo.com> In-Reply-To: <20041019162717.88731.qmail@web41206.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > As I mentioned earlier, if the WG can come up with a > well defined notion of what it means to be a link I'd > go for LE3 otherwise I'm in the LE0 court. > Kind of a nebulous requirement, don't you think? Could you expand on what a "well-defined notion" would be? Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 13:06:48 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 NAA16870 for ; Tue, 19 Oct 2004 13:06:47 -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 i9JGxHrD001550; Tue, 19 Oct 2004 09:59:17 -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 i9JGxHpg001549; Tue, 19 Oct 2004 09:59:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JGxGgC001526 for ; Tue, 19 Oct 2004 09:59:16 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041019165913.97903.qmail@web41205.mail.yahoo.com> Received: from [24.18.132.123] by web41205.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 09:59:13 PDT Date: Tue, 19 Oct 2004 09:59:13 -0700 (PDT) From: Dare Obasanjo Subject: Re: Options for link extensibility To: mint@franklinmint.fm Cc: Joe Gregorio , Tim Bray , Atom Syntax In-Reply-To: <417542E3.3040603@franklinmint.fm> 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: --- Robert Sayre wrote: > > Kind of a nebulous requirement, don't you think? > Could you expand on > what a "well-defined notion" would be? In practical terms, I want a description good enough that I can write one chunk of code for dealing with elements and it can deal with all the link elements that may show up either from the Atom WG or as extensions in a consistent AND useful manner. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 19 13:28: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 NAA18784 for ; Tue, 19 Oct 2004 13:28: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 i9JHLklx005295; Tue, 19 Oct 2004 10:21: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 i9JHLkvr005294; Tue, 19 Oct 2004 10:21:46 -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 i9JHLjFY005285 for ; Tue, 19 Oct 2004 10:21:45 -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 1CJxg9-0000kK-B1; Tue, 19 Oct 2004 17:21:45 +0000 Message-ID: <41754D2A.3080808@franklinmint.fm> Date: Tue, 19 Oct 2004 13:21:46 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Joe Gregorio , Tim Bray , Atom Syntax Subject: Re: Options for link extensibility References: <20041019165913.97903.qmail@web41205.mail.yahoo.com> In-Reply-To: <20041019165913.97903.qmail@web41205.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > In practical terms, I want a description good enough > that I can write one chunk of code for dealing with > elements and it can deal with all the link > elements that may show up either from the Atom WG or > as extensions in a consistent AND useful manner. > OK. Let's examine the current practice. Here's what Mozilla does with unknown link elements: http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/linkToolbarHandler.js#165 It ignores any link that contains a @rel value that includes: * stylesheet * icon * fontdef * p3pv * schema So, roughly, the resource pointed to by the link should be a standalone resource that could replace the entry in a viewport, not information or metadata related to policy or display of the entry. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 13:34:39 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 NAA19484 for ; Tue, 19 Oct 2004 13:34:38 -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 i9JHSKGf006287; Tue, 19 Oct 2004 10:28: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 i9JHSKH0006286; Tue, 19 Oct 2004 10:28:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHSIxG006256 for ; Tue, 19 Oct 2004 10:28:19 -0700 (PDT) (envelope-from johan@opera.com) Received: from capitole.oslo.opera.com (pc096.lan024.oslo.opera.com [10.20.24.96] (may be forged)) (authenticated bits=0) by sam.opera.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i9JHSDSd028693 for ; Tue, 19 Oct 2004 17:28:14 GMT Date: Tue, 19 Oct 2004 19:28:13 +0200 To: "atom-syntax.imc.org" Subject: Article importance From: "Johan H. Borg" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.60 (Win32, build 7247) X-Scanned-By: MIMEDefang 2.39 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, I'm new on the list, this may have been discussed earlier but I couldn't find anything about it easily. This question may or may not be relevant to this forum, but hopefully to some of its subscribers.. One thing that annoys me with RSS and Atom is this: There doesn't seem to be any way to indicate the relative importance of an article in a feed (?). Background: In e-mail there is the "Importance:" header, which in general isn't very usable since it's only used by a few senders, and those who use it tend to misuse it (like claiming that all their messages are important). For Atom it makes a whole lot more sense: When I subscribe to a feed I may not be interested in every single entry. OK, I may have a different definition of importance than the editor, but in many cases the editor will be able to say that this is the main headline of the day. Advantages: From a user interface perspective, knowing the relative importance of each entry in a feed can allow the receiving client to show a list of only the X most important items for each subscribed feed that day. This would be of great help not only on the desktop, but maybe in particular on a mobile device, where screen estate is of higher importance. It would also make it possible to warn the end user about important events without disturbing them when only minor updates are available. I believe this could enhance the user experience significantly. Implementation: Add something like an atom:importance element. The value could be from 1 to number of items in the feed, where 1 is the most important entry. Another way would be to let the author decide the value individually for each entry, from 1 to 10, where 10 is the most important. In either case it's easy for the client to compare the value against the average importance in the feed that day. Comments? Johan. From owner-atom-syntax@mail.imc.org Tue Oct 19 13:51: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 NAA22327 for ; Tue, 19 Oct 2004 13:51: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 i9JHga6i008276; Tue, 19 Oct 2004 10:42:36 -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 i9JHgZ4Z008275; Tue, 19 Oct 2004 10:42:35 -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 i9JHgZFK008269 for ; Tue, 19 Oct 2004 10:42:35 -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 1CJy0J-00040Y-I8; Tue, 19 Oct 2004 17:42:35 +0000 Message-ID: <41755207.9030706@franklinmint.fm> Date: Tue, 19 Oct 2004 13:42:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Johan H. Borg" CC: atom-syntax Subject: Re: Article importance References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; 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 Johan H. Borg wrote: > > Hi, > > > One thing that annoys me with RSS and Atom is this: > There doesn't seem to be any way to indicate the relative importance of > an article in a feed (?). > > In e-mail there is the "Importance:" header, which in general isn't > very usable since it's only used by a few senders, and those who use it > tend to misuse it (like claiming that all their messages are important). > > > Comments? Hi Johan, thanks for the suggestion. This sounds like a good candidate for an extension element (that would be useful for both Atom and RSS). The header for importance is usually "X-Priority", isn't it? For example, I generally turn off such alerts because I don't find them useful. Leaving these things for extensions lets the market decide. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 13:53:20 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 NAA22479 for ; Tue, 19 Oct 2004 13:53:19 -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 i9JHi9SA008475; Tue, 19 Oct 2004 10:44:09 -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 i9JHi99V008474; Tue, 19 Oct 2004 10:44:09 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHi8Kx008466 for ; Tue, 19 Oct 2004 10:44:08 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 19 Oct 2004 10:16:16 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: IANA registry vs. URIs Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wearing my co-chair and non-impelenter hats: The major difference between defining link type in an IANA registry or by URI is interoperability. If something is in the IANA registry and we have specified that you have to define what your registered type means, then an implementer can look in the IANA registry and figure out what this new link type means. They can't do that with a URI unless the URI dereferences to a description of what the link type means. The assumption that many people are making here is that the dereferencing will happen correctly for all time, and that the technical content at the URI will not change. IETF experience has proven those assumptions to be wrong again and again. A non-trivial example is that a viewer producer comes up with a new link type, bakes it into their viewer, and publishes the spec at the URI. A few months later, someone points out something wrong in their spec so they change it. Everyone who read the spec before the change is now screwed. Another non-trivial example is that the company forgets to renew its domain name and the link dies. One way to get around the problem of URIs no longer dereferencing, or changing, is for people who rely on the link to copy the contents and republish them in a well-known place. For instance, a vendor might create a publicly-accessible document that says "our product knows how to use link types A, B, and C, and here is what we are using as our basis for interpreting them". Assuming that the documents are longer-lived than the URIs and can be found by future implementers, this fixes both problems. Of course, both those assumptions have difficulty. Getting a new type registered in the IANA registry can definitely a pain in the butt, and some folks will simply not do it but will create new link types anyway. The IETF has lots of experience with this as well. We can make the IANA registration process as easy or as hard as we want, as long as a secretarial person at IANA can follow what we say. The question comes down to: is the high interoperability value of having a stable repository of definitions of link types worth the high cost of commonly-used link types that lose their definitions plus the cost of developers that don't bother to register at all? Historically in the IETF, the answer to similar questions has been "yes", but we can certainly answer that differently if we think the costs outweigh the benefits of an IANA registry. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 19 14:07:04 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 OAA24307 for ; Tue, 19 Oct 2004 14:07: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 i9JI0SEh011608; Tue, 19 Oct 2004 11:00: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 i9JI0RHJ011606; Tue, 19 Oct 2004 11:00:27 -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 i9JI0RIS011593; Tue, 19 Oct 2004 11:00: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 1CJyHb-0007pk-Sr; Tue, 19 Oct 2004 18:00:28 +0000 Message-ID: <4175563D.7080603@franklinmint.fm> Date: Tue, 19 Oct 2004 14:00:29 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: IANA registry vs. URIs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > The major difference between defining link type in an IANA registry or > by URI is interoperability. If something is in the IANA registry and we > have specified that you have to define what your registered type means, > then an implementer can look in the IANA registry and figure out what > this new link type means. They can't do that with a URI unless the URI > dereferences to a description of what the link type means. > > The assumption that many people are making here is that the > dereferencing will happen correctly for all time, and that the technical > content at the URI will not change. IETF experience has proven those > assumptions to be wrong again and again. That's not the assumption that I am making. We are not talking about automagical configuration of unknown links. What we are talking about is a way for people to formulate ad-hoc links that don't collide with other people's ad-hoc links. X-MailerURI: http://example.org/mailer becomes http://example.org-MailerURI: http://example.org/mailer That's it. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 14:12:43 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 OAA24776 for ; Tue, 19 Oct 2004 14:12:42 -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 i9JI7BFD012610; Tue, 19 Oct 2004 11:07:11 -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 i9JI7B33012609; Tue, 19 Oct 2004 11:07:11 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JI79jr012592; Tue, 19 Oct 2004 11:07:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <4175563D.7080603@franklinmint.fm> References: <4175563D.7080603@franklinmint.fm> Date: Tue, 19 Oct 2004 11:07:10 -0700 To: mint@franklinmint.fm From: Paul Hoffman / IMC Subject: Re: IANA registry vs. URIs Cc: Atom WG 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 2:00 PM -0400 10/19/04, Robert Sayre wrote: >That's not the assumption that I am making. We are not talking about >automagical configuration of unknown links. Agree, but... > What we are talking about is a way for people to formulate ad-hoc >links that don't collide with other people's ad-hoc links. And how would a Atom reader know what to do with the ad-hoc link? Where would the interoperability for that new link type come from? Or are you saying that there is no expectation of interoperability for these new link types? >X-MailerURI: http://example.org/mailer > >becomes > >http://example.org-MailerURI: http://example.org/mailer > >That's it. Well, heck, that's easy. We can add a sentence to Atom that says "any link type name that begins with the string 'x-' is for private use only." Then we're in the same mess as every other IETF protocol from the last 15 years that have private extension, but at least we're doing it the same way. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 19 14:24: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 OAA25683 for ; Tue, 19 Oct 2004 14:24: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 i9JICnBP013481; Tue, 19 Oct 2004 11:12:49 -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 i9JICnwN013480; Tue, 19 Oct 2004 11:12:49 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JICnKd013447 for ; Tue, 19 Oct 2004 11:12:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so155600rnb for ; Tue, 19 Oct 2004 11:12:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YOnxZeB4NfWwTWQzB48TlhhWb7jkTGg9T35bnEasZKpqqOamgRIyPrUPEJDkyEZKCHY1zfPIxtyVLc73e5VMy/zFXCo++3wQT9Qm88JRd40NYfaXfNVtjrexHV1RLqaUWDSIn+BOBG2V6TwIOmiOmWjTIHLzbEDpiTUyhErife8 Received: by 10.38.98.30 with SMTP id v30mr203024rnb; Tue, 19 Oct 2004 11:12:45 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 11:12:45 -0700 (PDT) Message-ID: <1f2ed5cd041019111221572a03@mail.gmail.com> Date: Tue, 19 Oct 2004 20:12:45 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: IANA registry vs. URIs Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm sorry Paul, but I don't think this is a fair comparison at all: If something is in the IANA registry > and we have specified that you have to define what your registered > type means, then an implementer can look in the IANA registry and > figure out what this new link type means. They can't do that with a > URI unless the URI dereferences to a description of what the link > type means. 1. You can't take an IANA registered string and dereference it to find its meaning. 2. If dereferencing was a necessary requirement of name definitions, then anything that relied on XML Namespaces would fail to work. Even if your comparison worked, then I would personally still prefer to see URIs used, because the registration barrier is high enough that I think people would simply tend to ignore it (like URI scheme registration). Whereas the barrier to using URIs is fairly low - domain name registration is relatively cheap. For example, when defining RDF vocabularies I've personally had absolutely no temptation to use http://w3.org/rdf/MyStuff when my alternatives have been e.g. http://dannyayers.com/rdf/MyStuff or e.g. http://purl.org/stuff/rdf/MyStuff, it's more natural to use an alternative that coincidentally does provide the necessary partitioning. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 15:08: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 PAA00148 for ; Tue, 19 Oct 2004 15:08:13 -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 i9JJ0apO021191; Tue, 19 Oct 2004 12:00:36 -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 i9JJ0aHB021190; Tue, 19 Oct 2004 12:00:36 -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 i9JJ0Z63021167; Tue, 19 Oct 2004 12:00:36 -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 1CJzDo-0001AY-5h; Tue, 19 Oct 2004 19:00:36 +0000 Message-ID: <41756452.3010604@franklinmint.fm> Date: Tue, 19 Oct 2004 15:00:34 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: Re: IANA registry vs. URIs References: <4175563D.7080603@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > At 2:00 PM -0400 10/19/04, Robert Sayre wrote: > > And how would a Atom reader know what to do with the ad-hoc link? Where > would the interoperability for that new link type come from? Or are you > saying that there is no expectation of interoperability for these new > link types? > An Atom reader should be able to safely dereference the linked resource, if the user is interested in the title. The link will also have a MIME type. > > > Well, heck, that's easy. We can add a sentence to Atom that says "any > link type name that begins with the string 'x-' is for private use > only." Then we're in the same mess as every other IETF protocol from the > last 15 years that have private extension, but at least we're doing it > the same way. Given current practice in syndication, I don't think we have a choice. There will be private extension. Second, your suggestion assumes that link types will be in attribute values, rather than be elements themselves. We have to support XML Namespaces, right? Why do we need multiple collision-prevention mechanisms? I guess you could say my POV is that we have three choices: * Use XML Namespaces. * Drop XML Namespaces, and require "x-" or IANA registration for every element used in Atom. * Do both I know we aren't supposed to be discussing syntax, but I think we've gotten ourselves into this mess because of the syntax of the link element. I mean, we could define the Text construct similarly: ... ... ... Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 15:09: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 PAA00312 for ; Tue, 19 Oct 2004 15:09:16 -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 i9JJ2wxj021642; Tue, 19 Oct 2004 12:02:58 -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 i9JJ2wZs021641; Tue, 19 Oct 2004 12:02:58 -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 ESMTP id i9JJ2uIR021632 for ; Tue, 19 Oct 2004 12:02:58 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so158911rnb for ; Tue, 19 Oct 2004 12:02:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=sg9Ctn/klx+icpX5goUba6ZlyNCGyrzgg7gvkDCu9iuTd7gO6btqa4VhrJFnudHBGGGSwB8HwUH+Efwo7tljLeBNSatb7v8uzKpkXuijA00P2AFqlhuLBX4KLVfE6fmmTwX5vPhKSe7W88dC6u24b+dOftfuVDrF1qEF3b/7Z5c Received: by 10.38.98.30 with SMTP id v30mr226116rnb; Tue, 19 Oct 2004 12:02:58 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 12:02:58 -0700 (PDT) Message-ID: <1f2ed5cd0410191202195c48f4@mail.gmail.com> Date: Tue, 19 Oct 2004 21:02:58 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Options for link extensibility Cc: Dare Obasanjo , Joe Gregorio , Tim Bray , Atom Syntax In-Reply-To: <41754D2A.3080808@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041019165913.97903.qmail@web41205.mail.yahoo.com> <41754D2A.3080808@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > LE3 URIs: Non-centralized extensibility is achieved by using URIs to > > name types of links. +1 > First, isn't it a bit backward to be talking about link extensibility > before talking about general format extensibility? Yes. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 15:14:07 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 PAA00929 for ; Tue, 19 Oct 2004 15:14: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 i9JJ6wis022297; Tue, 19 Oct 2004 12:06:58 -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 i9JJ6wtg022296; Tue, 19 Oct 2004 12:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JJ6vkS022280 for ; Tue, 19 Oct 2004 12:06:57 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041019190656.29014.qmail@web41205.mail.yahoo.com> Received: from [131.107.71.94] by web41205.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 12:06:56 PDT Date: Tue, 19 Oct 2004 12:06:56 -0700 (PDT) From: Dare Obasanjo Subject: Re: IANA registry vs. URIs To: Paul Hoffman / IMC , mint@franklinmint.fm Cc: Atom WG In-Reply-To: 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: --- Paul Hoffman / IMC wrote: > > And how would a Atom reader know what to do with the > ad-hoc link? > Where would the interoperability for that new link > type come from? Or > are you saying that there is no expectation of > interoperability for > these new link types? Expecting an Atom reader to some how "learn" what to do with an ad-hoc link simply given a URI is venturing on AI. > >X-MailerURI: http://example.org/mailer > > > >becomes > > > >http://example.org-MailerURI: > http://example.org/mailer > > > >That's it. > > Well, heck, that's easy. We can add a sentence to > Atom that says "any > link type name that begins with the string 'x-' is > for private use > only." Then we're in the same mess as every other > IETF protocol from > the last 15 years that have private extension, but > at least we're > doing it the same way. URIs are supposed to reduce the likelihood of collision between parties creating custom links. However as you point out experience has shown that such collisions rarely occur in practice as is evidenced by the various IETF specs which use the 'x-' prefix extension mechanism. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 19 15:37:11 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 PAA03832 for ; Tue, 19 Oct 2004 15:37:10 -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 i9JJSrev026134; Tue, 19 Oct 2004 12:28: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 i9JJSrwL026133; Tue, 19 Oct 2004 12:28:53 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JJSk4p026117; Tue, 19 Oct 2004 12:28:47 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd041019111221572a03@mail.gmail.com> <20041019190656.29014.qmail@web41205.mail.yahoo.com> <41756452.3010604@franklinmint.fm> References: <1f2ed5cd041019111221572a03@mail.gmail.com> <20041019190656.29014.qmail@web41205.mail.yahoo.com> <4175563D.7080603@franklinmint.fm> <41756452.3010604@franklinmint.fm> Date: Tue, 19 Oct 2004 12:28:47 -0700 To: Danny Ayers , mint@franklinmint.fm, Dare Obasanjo From: Paul Hoffman / IMC Subject: Re: IANA registry vs. URIs Cc: Atom WG 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 8:12 PM +0200 10/19/04, Danny Ayers wrote: >1. You can't take an IANA registered string and dereference it to find >its meaning. Of course not. You have to go look in the IANA registry. It's in a well-known and stable location that is relied on by every implementer of IETF protocols. >2. If dereferencing was a necessary requirement of name definitions, >then anything that relied on XML Namespaces would fail to work. You're missing the point completely. Link *types* have some semantics. The URL that is used for the extension *of the type* is what tells you the semantics. At 3:00 PM -0400 10/19/04, Robert Sayre wrote: >An Atom reader should be able to safely dereference the linked >resource, if the user is interested in the title. The link will also >have a MIME type. Fully agree. My statement is about whether we care about the semantics of the new types. >>Well, heck, that's easy. We can add a sentence to Atom that says >>"any link type name that begins with the string 'x-' is for private >>use only." Then we're in the same mess as every other IETF protocol >>from the last 15 years that have private extension, but at least >>we're doing it the same way. > >Given current practice in syndication, I don't think we have a >choice. There will be private extension. Second, your suggestion >assumes that link types will be in attribute values, rather than be >elements themselves. True, but it could be extended to the elements in the same way. >We have to support XML Namespaces, right? Of course. > Why do we need multiple collision-prevention mechanisms? We are not talking only about collision-prevention: we are also talking about the semantics of the extended link types. Or, at least I thought we were talking about that. If we don't care anything about the semantics of them, then you can ignore everything I said. But, of course, the extensions will be nearly useless because Atom readers won't be able to do anything with the link other than to let the user deference it without any context ("is this about the entry, is this with the entry, is this a picture of the person who wrote the entry, is this the sound he made as he typed the entry, ..."). At 12:06 PM -0700 10/19/04, Dare Obasanjo wrote: >Expecting an Atom reader to some how "learn" what to >do with an ad-hoc link simply given a URI is venturing >on AI. Fully agree. The registry or deferencable link type names are for the humans like you who are updating their Atom reader software to handle the new link types. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 19 15:43:42 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 PAA04461 for ; Tue, 19 Oct 2004 15:43:42 -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 i9JJbpTY027566; Tue, 19 Oct 2004 12:37:51 -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 i9JJbpTP027565; Tue, 19 Oct 2004 12:37:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JJboeR027536; Tue, 19 Oct 2004 12:37:50 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao06.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041019193747.HTZJ5664.fed1rmmtao06.cox.net@[192.168.0.100]>; Tue, 19 Oct 2004 15:37:47 -0400 In-Reply-To: References: <4175563D.7080603@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom WG From: "Roy T. Fielding" Subject: Re: IANA registry vs. URIs Date: Tue, 19 Oct 2004 12:37:49 -0700 To: Paul Hoffman / IMC X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Well, heck, that's easy. We can add a sentence to Atom that says "any > link type name that begins with the string 'x-' is for private use > only." Then we're in the same mess as every other IETF protocol from > the last 15 years that have private extension, but at least we're > doing it the same way. No, then you would just have a broken protocol, like all of the ones in the IETF that specify "x-". The point of using URIs is to provide hierarchical delegation down to the point of easy avoidance of name collisions. x-prefixes does nothing to help that and, in fact, is known to be actively harmful to interoperability. The reasonable alternative is to make the field a URI-reference with a base URI equal to that of the IANA registry. That way, people who take the time to register a valuable name are rewarded with a short syntax, while the folks who want complete control of the specificity of their link types can mint their own URIs. Eventually, life will sort itself out and all of the significantly deployed types will become registered, and none of the insignificantly deployed types will collide with each other. Cheers, Roy T. Fielding Chief Scientist, Day Software From owner-atom-syntax@mail.imc.org Tue Oct 19 15:50:24 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 PAA05216 for ; Tue, 19 Oct 2004 15:50:23 -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 i9JJhRcH028378; Tue, 19 Oct 2004 12:43:27 -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 i9JJhRFP028377; Tue, 19 Oct 2004 12:43:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JJhPcn028318 for ; Tue, 19 Oct 2004 12:43:26 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 3576 invoked by uid 65534); 19 Oct 2004 19:43:17 -0000 Received: from dsl-213-023-054-011.arcor-ip.net (EHLO voyager) (213.23.54.11) by mail.gmx.net (mp003) with SMTP; 19 Oct 2004 21:43:17 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman / IMC Cc: Atom WG Subject: Re: IANA registry vs. URIs Date: Tue, 19 Oct 2004 21:43:09 +0200 Message-ID: <41ca601f.393982276@smtp.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: >The major difference between defining link type in an IANA registry >or by URI is interoperability. If something is in the IANA registry >and we have specified that you have to define what your registered >type means, then an implementer can look in the IANA registry and >figure out what this new link type means. They can't do that with a >URI unless the URI dereferences to a description of what the link >type means. A registry further helps to answer questions such as: * Is there already a link type with the desired "meaning"? * Which link types can I use to do what I want? * Which link types should be implemented in my product? * What do people think about my proposed extension? And it would yield in a number of desired properties of new link types such as neutrality (no need to put names of persons or organization in the document to use the extension). From owner-atom-syntax@mail.imc.org Tue Oct 19 15:51:20 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 PAA05382 for ; Tue, 19 Oct 2004 15:51:19 -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 i9JJihh3028556; Tue, 19 Oct 2004 12:44:43 -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 i9JJihXX028555; Tue, 19 Oct 2004 12:44:43 -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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JJigKJ028549 for ; Tue, 19 Oct 2004 12:44:42 -0700 (PDT) (envelope-from bskahan@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so769084rnl for ; Tue, 19 Oct 2004 12:44:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=b+NAfMEQg1BDMWtlGTRAG4wb6/gTEmzq0Tk9NA6S+pPglcbkJjebE7HN9Z1c4P6ShY8M/7Xt77fJGEkZXXnY+loI+TVRKjQs0w9e3QD3hugg/J9rzL0Sr+Z+OXdl3yBZdI1cFkqi7RFEUrzufo0Iol10CXE5MiFn01UiG+PzjQk Received: by 10.38.181.77 with SMTP id d77mr2142138rnf; Tue, 19 Oct 2004 12:44:46 -0700 (PDT) Received: by 10.38.86.39 with HTTP; Tue, 19 Oct 2004 12:44:46 -0700 (PDT) Message-ID: Date: Tue, 19 Oct 2004 15:44:46 -0400 From: Brian Skahan Reply-To: bskahan@etria.com To: atom-syntax Subject: Re: Article importance In-Reply-To: <41755207.9030706@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41755207.9030706@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 13:42:31 -0400, Robert Sayre wrote: > > > In e-mail there is the "Importance:" header, which in general isn't > > very usable since it's only used by a few senders, and those who use it > > tend to misuse it (like claiming that all their messages are important). > > > > The header for importance is usually "X-Priority", isn't it? For > example, I generally turn off such alerts because I don't find them > useful. Leaving these things for extensions lets the market decide. > Sadly, I think this would just get misused, even as an extension. I think the better solution is for clients to learn what you think is important. -Brian -- Brian Skahan http://bskahan.etria.com From owner-atom-syntax@mail.imc.org Tue Oct 19 15:51: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 PAA05389 for ; Tue, 19 Oct 2004 15:51:20 -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 i9JJjoYO028704; Tue, 19 Oct 2004 12: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 i9JJjo0h028703; Tue, 19 Oct 2004 12:45:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao09.cox.net (fed1rmmtao09.cox.net [68.230.241.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JJjomA028686 for ; Tue, 19 Oct 2004 12:45:50 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao09.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041019194549.PCRY21535.fed1rmmtao09.cox.net@[192.168.0.100]> for ; Tue, 19 Oct 2004 15:45:49 -0400 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41756452.3010604@franklinmint.fm> References: <4175563D.7080603@franklinmint.fm> <41756452.3010604@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <79EBD004-2207-11D9-8A83-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: IANA registry vs. URIs Date: Tue, 19 Oct 2004 12:45:48 -0700 To: Atom WG X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > We have to support XML Namespaces, right? Why do we need multiple > collision-prevention mechanisms? Because use of qnames in content should be avoided at all costs. XML Namespaces are a tuple-space for XML parsers. Using tuple-spaces for hierarchical names is a bad idea outside the context of SGML/XML restrictions on NAME characters, and should not be repeated anywhere else. ....Roy From owner-atom-syntax@mail.imc.org Tue Oct 19 15:52: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 PAA05605 for ; Tue, 19 Oct 2004 15:52: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 i9JJi6av028487; Tue, 19 Oct 2004 12:44: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 i9JJi6tr028486; Tue, 19 Oct 2004 12:44:06 -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 i9JJi5H8028465; Tue, 19 Oct 2004 12:44:05 -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 1CJztu-00013N-75; Tue, 19 Oct 2004 19:44:06 +0000 Message-ID: <41756E87.9020202@franklinmint.fm> Date: Tue, 19 Oct 2004 15:44:07 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Danny Ayers , Dare Obasanjo , Atom WG Subject: Re: IANA registry vs. URIs References: <1f2ed5cd041019111221572a03@mail.gmail.com> <20041019190656.29014.qmail@web41205.mail.yahoo.com> <4175563D.7080603@franklinmint.fm> <41756452.3010604@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > We are not talking only about collision-prevention: we are also talking > about the semantics of the extended link types. Or, at least I thought > we were talking about that. If we don't care anything about the > semantics of them, then you can ignore everything I said. But, of > course, the extensions will be nearly useless because Atom readers won't > be able to do anything with the link other than to let the user > deference it without any context ("is this about the entry, is this with > the entry, is this a picture of the person who wrote the entry, is this > the sound he made as he typed the entry, ..."). > Ok, I understand what you mean now. I noticed as I was making a demo of the Mozilla feature that @rel in HTML is overloaded. It serves as a type and a human description. I think we should split them up. Here's that demo: http://franklinmint.fm/2004/10/19/links.html Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 15:57: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 PAA06518 for ; Tue, 19 Oct 2004 15:57:43 -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 i9JJoh3X029785; Tue, 19 Oct 2004 12:50:43 -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 i9JJogeM029783; Tue, 19 Oct 2004 12:50:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JJofJ7029753 for ; Tue, 19 Oct 2004 12:50:42 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 23425 invoked by uid 65534); 19 Oct 2004 19:50:39 -0000 Received: from dsl-213-023-054-011.arcor-ip.net (EHLO voyager) (213.23.54.11) by mail.gmx.net (mp022) with SMTP; 19 Oct 2004 21:50:39 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Danny Ayers Cc: atom-syntax@imc.org Subject: Re: IANA registry vs. URIs Date: Tue, 19 Oct 2004 21:50:31 +0200 Message-ID: <41cb6e8b.397675016@smtp.bjoern.hoehrmann.de> References: <1f2ed5cd041019111221572a03@mail.gmail.com> In-Reply-To: <1f2ed5cd041019111221572a03@mail.gmail.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Danny Ayers wrote: >1. You can't take an IANA registered string and dereference it to find >its meaning. Why not? >2. If dereferencing was a necessary requirement of name definitions, >then anything that relied on XML Namespaces would fail to work. Did anyone propose this as an absolute requirement? >Even if your comparison worked, then I would personally still prefer >to see URIs used, because the registration barrier is high enough that >I think people would simply tend to ignore it (like URI scheme >registration). Whereas the barrier to using URIs is fairly low - >domain name registration is relatively cheap. Why does this matter exactly? From owner-atom-syntax@mail.imc.org Tue Oct 19 16:35: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 QAA10737 for ; Tue, 19 Oct 2004 16:35: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 i9JKR3Vx035196; Tue, 19 Oct 2004 13:27:03 -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 i9JKR3Ej035195; Tue, 19 Oct 2004 13:27:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JKR2E0035177 for ; Tue, 19 Oct 2004 13:27:03 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9JKQHlJ008991; Tue, 19 Oct 2004 16:26:58 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BVL52159 (AUTH bob@wyman.us); Tue, 19 Oct 2004 16:26:14 -0400 (EDT) Message-Id: <200410192026.BVL52159@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Henry Story'" , "'Atom Syntax'" Subject: RE: Bell on Standards Date: Tue, 19 Oct 2004 16:26:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS0MUu4dDeumODVSWavQTK8iDeLsQB5uX/Q In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > But then Gordon Bell is working for Microsoft, so this blindness > is not so surprising. This sort of libel has no place in this group. Your cheap shot at Gordon Bell merely proves that you have no idea of the man's contribution to this industry -- long before Microsoft decided to fund his retirement... If Bell fails to praise Unix it is probably because he remembers the long years during which Unix offered little more than pipes as the solution to all issues of componentization. Gordon Bell, on the other hand, led the development efforts at Digital that resulted in such innovations as the Common Runtime Library for all languages on VMS, shared libraries, common calling standards, layered product architectures, etc. that were the real introducers of the idea of componentization to the software world. But, one would have to understand and care about history in order to know these things and many others... Unfortunately, understanding history takes much more effort then the cheap shot you delivered. bob wyman From owner-atom-syntax@mail.imc.org Tue Oct 19 17:06: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 RAA13209 for ; Tue, 19 Oct 2004 17:05:59 -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 i9JKxO3k040112; Tue, 19 Oct 2004 13:59: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 i9JKxOmi040111; Tue, 19 Oct 2004 13:59:24 -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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JKxMWc040090 for ; Tue, 19 Oct 2004 13:59:22 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so166142rnb for ; Tue, 19 Oct 2004 13:59:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bv3Ja4+oqV5AppPWwk80XAkycWhCyLsqfsgrmC+6szd2VH/kjpSYH/zCaXal+1qDFlNnh2h5PDlQXTgiqgc/B1y/4yWe/Sz+iGttgVj1NDomfwItpVzfry9z6Unt09XBswRVLMnsPuBJIn3ELMsQq+1v5AYeAkx+h9BjffW1YqU Received: by 10.38.179.56 with SMTP id b56mr1212472rnf; Tue, 19 Oct 2004 13:59:23 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 13:59:23 -0700 (PDT) Message-ID: <1f2ed5cd04101913596927164c@mail.gmail.com> Date: Tue, 19 Oct 2004 22:59:23 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: IANA registry vs. URIs Cc: mint@franklinmint.fm, Dare Obasanjo , Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4175563D.7080603@franklinmint.fm> <1f2ed5cd041019111221572a03@mail.gmail.com> <20041019190656.29014.qmail@web41205.mail.yahoo.com> <41756452.3010604@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 12:28:47 -0700, Paul Hoffman / IMC wrote: > At 8:12 PM +0200 10/19/04, Danny Ayers wrote: > >1. You can't take an IANA registered string and dereference it to find > >its meaning. > > Of course not. You have to go look in the IANA registry. It's in a > well-known and stable location that is relied on by every implementer > of IETF protocols. The inability to dereference was one of your main arguments against URIs. I'm simply suggesting you apply the same criteria to both options. On the other hand, you could set up a well-known location for finding URI semantics (though I don't actually think that would be good approach beyond informative docs). > >2. If dereferencing was a necessary requirement of name definitions, > >then anything that relied on XML Namespaces would fail to work. > > You're missing the point completely. Link *types* have some > semantics. The URL that is used for the extension *of the type* is > what tells you the semantics. Maybe I am missing the point, but as I understand the relevant proposal (which I wrote) a URI will be used as an identifier for the link type, in a similar way as an IANA-registered value would be. The maintenance of the name is a separate issue from discovery of the semantics of a particular type. There is considerable prior art in the use of URIs for typing link-like constructs [1], [2], [3]. I'm not aware of any that have found IANA registration necessary. I don't think it's strictly relevant, but discovery of the semantics would probably be easier using a URI as it could /potentially/ be deferenced (the spec could even mandate it) and standard techniques such as RDDL, WSDL, RDF Schema and/or OWL used to provide semantics. None of the IANA registries I've encountered have provided material in a form that would be easy for an application to interpret. At 12:06 PM -0700 10/19/04, Dare Obasanjo wrote: >Expecting an Atom reader to some how "learn" what to >do with an ad-hoc link simply given a URI is venturing >on AI. "learn"? At it's most sophisticated I think we're talking about the reader downloading a plugin. An Atom reader could fairly easily look up how to interpret an ad hoc link type, it might even involve behaviour. But I think it would be a stretch to call process/service identifiers AI. Cheers, Danny. [1] http://www.w3.org/TR/xlink/ [2] http://www.topicmaps.org/xtm/1.0/#elt-subjectIndicatorRef [3] http://www.w3.org/TR/rdf-schema/#ch_properties -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 17:19: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 RAA14165 for ; Tue, 19 Oct 2004 17:19: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 i9JLCItr041940; Tue, 19 Oct 2004 14:12: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 i9JLCI1l041939; Tue, 19 Oct 2004 14:12:18 -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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JLCHWm041925 for ; Tue, 19 Oct 2004 14:12:17 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so166848rnb for ; Tue, 19 Oct 2004 14:12:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RGRiEFD6m9LXalmxb0zql1a44OzHLcBQIKbtXS0i5Lc9cGhl3BpQ8t4GkbnFC4SeUGWLFYCGOvCoMfSoeZpxurB5nlvlNTM684xaNt6ZRmd6xRpbkQtemhqmrMQ17bumfhO3PN7x6NeXDELKhH9CmXpXGR1JQVbSxvAGv6OtOeE Received: by 10.38.179.56 with SMTP id b56mr1217841rnf; Tue, 19 Oct 2004 14:12:21 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 14:12:21 -0700 (PDT) Message-ID: <1f2ed5cd041019141243df13a6@mail.gmail.com> Date: Tue, 19 Oct 2004 23:12:21 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Bjoern Hoehrmann Subject: Re: IANA registry vs. URIs Cc: atom-syntax@imc.org In-Reply-To: <41cb6e8b.397675016@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041019111221572a03@mail.gmail.com> <41cb6e8b.397675016@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 21:50:31 +0200, Bjoern Hoehrmann wrote: > * Danny Ayers wrote: > >1. You can't take an IANA registered string and dereference it to find > >its meaning. > > Why not? Fair point. Try: "You can't take an arbitrary IANA registered string and dereference it using any well-known protocol it to find its meaning." > >2. If dereferencing was a necessary requirement of name definitions, > >then anything that relied on XML Namespaces would fail to work. > > Did anyone propose this as an absolute requirement? No, but it formed a significant part of Paul's argument. > >Even if your comparison worked, then I would personally still prefer > >to see URIs used, because the registration barrier is high enough that > >I think people would simply tend to ignore it (like URI scheme > >registration). Whereas the barrier to using URIs is fairly low - > >domain name registration is relatively cheap. > > Why does this matter exactly? Standardization is useful for interoperability. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 17:29: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 RAA15230 for ; Tue, 19 Oct 2004 17:29: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 i9JLNPpI043562; Tue, 19 Oct 2004 14:23:25 -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 i9JLNP98043561; Tue, 19 Oct 2004 14:23:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JLNOck043554 for ; Tue, 19 Oct 2004 14:23:24 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9JLNMq5013510; Tue, 19 Oct 2004 17:23:26 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BVL72637 (AUTH bob@wyman.us); Tue, 19 Oct 2004 17:23:21 -0400 (EDT) Message-Id: <200410192123.BVL72637@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Johan H. Borg'" , "'atom-syntax.imc.org'" Subject: RE: Article importance Date: Tue, 19 Oct 2004 17:23:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS2CFXg7fHD5TUcTmGhRGlmQpI3dwAEau6Q In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Johan H. Borg wrote: > There doesn't seem to be any way to indicate the relative > importance of an article in a feed (?). If you dig into this thought a bit, I think you'll find some very difficult questions to answer. For instance, what is the scope of any metric of importance? What is it that you mean when you say "a feed"? Are you speaking of the conceptual "feed" that is the series of all entries that have been published since the "feed" was created and will be published to the feed in the future? Or, are you referring to just those items that might be in a particular instance of an Atom file? (i.e. a sliding window on the head of the feed) If you are referring to an Atom file, then how would importance be handled if the entries are individually copied into an aggregate feed or distributed one at a time via a protocol such as "Atom over XMPP?" Given that more and more people are using RFC3229+feed[1] when publishing and retrieving Atom feeds, the idea of "Atom file" begins to make less and less sense. How can a file specific concept be maintained if different clients have different ideas of what constitutes the file? If you have a fixed scale of importance (perhaps 1 to 10), then what do you do when you publish a new entry whose "importance" is greater than all previously published entries yet you've already used the highest measure for something in the past? Can the scale of importance be anything other than open ended? Importance may tend to decay over time. Would you define such a decay function? Sometimes, the importance of an old entry might be considered to increase after it is published. If this happens, would you have people republish items to adjust their importance metrics? It is best to think of Atom in terms of entries, not feeds. Remember the slogan: "It's the Entries, Stupid!"... bob wyman [1] http://bobwyman.pubsub.com/main/2004/09/implementations.html http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html From owner-atom-syntax@mail.imc.org Tue Oct 19 17:30: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 RAA15329 for ; Tue, 19 Oct 2004 17:30:46 -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 i9JLP8nj043858; Tue, 19 Oct 2004 14:25: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 i9JLP88d043857; Tue, 19 Oct 2004 14:25:08 -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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JLP765043830 for ; Tue, 19 Oct 2004 14:25:08 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so167573rnb for ; Tue, 19 Oct 2004 14:25:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=MZ0ohK6AWhFMs63J8rOvTVK2zcvwNhgpSWcoxlcdTtZJZm5wtiWCJ/NwFnoaSNgHSxhS3vDN9kofH6px91JQA8X+PAHRoF6gy+4qZPrE9lC1KZh9B0ZTPQTOHtA3y453K5FLcx5U0464OwQ1LRxkUuTO/LHNvq/yePbqef7y2a0 Received: by 10.38.179.56 with SMTP id b56mr1223110rnf; Tue, 19 Oct 2004 14:25:09 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 14:25:09 -0700 (PDT) Message-ID: <1f2ed5cd04101914252de36b86@mail.gmail.com> Date: Tue, 19 Oct 2004 23:25:09 +0200 From: Danny Ayers Reply-To: Danny Ayers To: bskahan@etria.com Subject: Re: Article importance Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41755207.9030706@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd go with Robert on this one - it's a good idea, appropriate for an extension (probably not using X-Priority as such). Thing is that there are also a lot of other potential value scales that could usefully be delivered - if the app was a project manager you might have separate 'urgency' and 'importance' measures. A couple of other possibles I've been mulling over (for some client-side stuff) are 'relevance' and 'proximity'. Relevance to a particular topic could be used for filtering the cat photos out of Planet Goldfish, for instance. Proximity I was thinking of in terms of a kind of combined/generalised measure between two entities (entries, people, events, whatever), again for filtering down info overload. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 17:32:33 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 RAA15424 for ; Tue, 19 Oct 2004 17:32:32 -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 i9JLQqBb044094; Tue, 19 Oct 2004 14:26: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 i9JLQqKL044090; Tue, 19 Oct 2004 14:26: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 i9JLQphq044053 for ; Tue, 19 Oct 2004 14:26:52 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 6937B7C2E7; Tue, 19 Oct 2004 23:24:38 +0200 (CEST) Date: Tue, 19 Oct 2004 23:30:28 +0200 To: "Tim Bray" Subject: Re: Options for link extensibility Cc: Atom-Syntax References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 18 Oct 2004 13:33:48 -0700, Tim Bray wrote: > LE3 URIs: Non-centralized extensibility is achieved by using URIs to > name types of links. I'm +1 on this, but would like it to be either recommended or required that the URI's are dereferencable so that the meaning of it can be explained to the human implementing support for a given URI. Namespaces almost always deploy this practice today, but it isn't very clear what you are to expect at the end of a namespace HTTP URI. I'd like that to be clear, or would at least like there to be provided some guidelines, in this case. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Oct 19 17:37:04 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 RAA16394 for ; Tue, 19 Oct 2004 17:37: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 i9JLTQe1044429; Tue, 19 Oct 2004 14:29:26 -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 i9JLTQx9044428; Tue, 19 Oct 2004 14:29:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JLTPTC044415; Tue, 19 Oct 2004 14:29:25 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9JLTTNH015972; Tue, 19 Oct 2004 15:29:30 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5U00APTP1502@edgemail1.Central.Sun.COM>; Tue, 19 Oct 2004 15:29:29 -0600 (MDT) Received: from [66.103.196.111] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5U00BJPP14U9@mail.sun.net>; Tue, 19 Oct 2004 15:29:29 -0600 (MDT) Date: Tue, 19 Oct 2004 14:29:55 -0700 From: Tim Bray Subject: Re: IANA registry vs. URIs In-reply-to: <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> To: "Roy T. Fielding" Cc: Paul Hoffman / IMC , Atom WG Message-id: <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4175563D.7080603@franklinmint.fm> <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 19, 2004, at 12:37 PM, Roy T. Fielding wrote: > The reasonable alternative is to make the field a URI-reference > with a base URI equal to that of the IANA registry. That way, people > who take the time to register a valuable name are rewarded with a > short syntax, while the folks who want complete control of the > specificity of their link types can mint their own URIs. Eventually, > life will sort itself out and all of the significantly deployed types > will become registered, and none of the insignificantly deployed > types will collide with each other. I'll write up a Pace to formalize this proposal. It sounds uncluttered and sane to me. -Tim From owner-atom-syntax@mail.imc.org Tue Oct 19 17:37:33 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 RAA16461 for ; Tue, 19 Oct 2004 17:37:32 -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 i9JLUvCu044600; Tue, 19 Oct 2004 14:30: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 i9JLUvxs044599; Tue, 19 Oct 2004 14:30: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 i9JLUul2044584 for ; Tue, 19 Oct 2004 14:30:56 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 044BC7C2E7; Tue, 19 Oct 2004 23:28:50 +0200 (CEST) Date: Tue, 19 Oct 2004 23:34:40 +0200 To: sc@itst.net Subject: Re: Time to add advertising to Atom? Cc: Atom-Syntax References: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> 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: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 19 Oct 2004 12:52:41 +0200 (CEST), Sascha Carlin wrote: > Why not implement an attribute for atom:item called ad="ad" like its done > with checked="checked" within XHTML? I think the problem is a bit bigger than this, but it would nonetheless be trivial and unproblematic to add an 'ad:ad="ad"' attribute to the atom:entry element. Not sure that solves it all, though. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Oct 19 17:55: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 RAA18920 for ; Tue, 19 Oct 2004 17:55:46 -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 i9JLoNNE047790; Tue, 19 Oct 2004 14:50: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 i9JLoNDp047789; Tue, 19 Oct 2004 14:50:23 -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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JLoMJr047768 for ; Tue, 19 Oct 2004 14:50:22 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so168791rnb for ; Tue, 19 Oct 2004 14:50:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=VMh52/APe2XXvNc4H4lrD9dgeI2B2pmSeAxpQLw6kRaJ4kGhYUbLdCue5ofIHa7wuMQn52AHCeg8pG4+LAYBJhhFpD1oVJh+BO/q+nd4suCM+CVlwTI7kDgox27DiptwKQYeXHXSaAqs/5GoWT9loLTUJci2rsAvLXNjFmbW6U4 Received: by 10.38.206.72 with SMTP id d72mr1282122rng; Tue, 19 Oct 2004 14:50:22 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 14:50:22 -0700 (PDT) Message-ID: <1f2ed5cd041019145049e49c35@mail.gmail.com> Date: Tue, 19 Oct 2004 23:50:22 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: IANA registry vs. URIs Cc: "Roy T. Fielding" , Paul Hoffman / IMC , Atom WG In-Reply-To: <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4175563D.7080603@franklinmint.fm> <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 14:29:55 -0700, Tim Bray wrote: > > On Oct 19, 2004, at 12:37 PM, Roy T. Fielding wrote: > > > The reasonable alternative is to make the field a URI-reference > > with a base URI equal to that of the IANA registry. That way, people > > who take the time to register a valuable name are rewarded with a > > short syntax, while the folks who want complete control of the > > specificity of their link types can mint their own URIs. Eventually, > > life will sort itself out and all of the significantly deployed types > > will become registered, and none of the insignificantly deployed > > types will collide with each other. > > I'll write up a Pace to formalize this proposal. It sounds uncluttered > and sane to me. -Tim Thanks. I don't see any harm in this approach, but have yet to see any convincing argument as to why IANA registration should be needed, what benefits it brings. Ok, there may be a predefined process for registering names. But for the context of syndication it seems to be just enough trouble that people ignore it (e.g. the feed: URI scheme). A centralised location for documentation could be associated with the Atom namespace(s). Looking at Roy's prognosis: Eventually, > > life will sort itself out and all of the significantly deployed types > > will become registered, and none of the insignificantly deployed > > types will collide with each other. What has actually been gained from the registration of the significantly deployed types? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 17:55:49 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 RAA18942 for ; Tue, 19 Oct 2004 17:55:48 -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 i9JLmRPi047428; Tue, 19 Oct 2004 14:48:27 -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 i9JLmR3L047427; Tue, 19 Oct 2004 14:48:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JLmPqH047403 for ; Tue, 19 Oct 2004 14:48:26 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 23015 invoked by uid 65534); 19 Oct 2004 21:48:25 -0000 Received: from dsl-213-023-054-011.arcor-ip.net (EHLO voyager) (213.23.54.11) by mail.gmx.net (mp023) with SMTP; 19 Oct 2004 23:48:25 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Danny Ayers Cc: atom-syntax@imc.org Subject: Re: IANA registry vs. URIs Date: Tue, 19 Oct 2004 23:48:15 +0200 Message-ID: <41d28574.403539348@smtp.bjoern.hoehrmann.de> References: <1f2ed5cd041019111221572a03@mail.gmail.com> <41cb6e8b.397675016@smtp.bjoern.hoehrmann.de> <1f2ed5cd041019141243df13a6@mail.gmail.com> In-Reply-To: <1f2ed5cd041019141243df13a6@mail.gmail.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Danny Ayers wrote: >On Tue, 19 Oct 2004 21:50:31 +0200, Bjoern Hoehrmann wrote: >> * Danny Ayers wrote: >> >1. You can't take an IANA registered string and dereference it to find >> >its meaning. >> >> Why not? > >Fair point. Try: "You can't take an arbitrary IANA registered string >and dereference it using any well-known protocol it to find its >meaning." Google is a well-known protocol to find out about everything of common interest. Typing `http://example.org/atom/link-type/foo` rather than `google atom link type foo` into the address bar of my browser does not buy me much if anything. >> >Even if your comparison worked, then I would personally still prefer >> >to see URIs used, because the registration barrier is high enough that >> >I think people would simply tend to ignore it (like URI scheme >> >registration). Whereas the barrier to using URIs is fairly low - >> >domain name registration is relatively cheap. >> >> Why does this matter exactly? > >Standardization is useful for interoperability. Standardization by removing rules has an impact on interoperability? From owner-atom-syntax@mail.imc.org Tue Oct 19 18:07:12 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 SAA20217 for ; Tue, 19 Oct 2004 18:07:12 -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 i9JM12FM049748; Tue, 19 Oct 2004 15:01: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 i9JM12YN049747; Tue, 19 Oct 2004 15:01:02 -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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JM120t049708 for ; Tue, 19 Oct 2004 15:01:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so169331rnb for ; Tue, 19 Oct 2004 15:01:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HOgb3giU/yo1vckIDCaffv6h+mwlelaSBBOMJ+/Yb9cFA9iYaAFpZ9A2n0gLXBh0TVMXtEiATD1j+2//5ujl6nf5ZeWgwKWH2mqrm2Cc5HW4Ip+CFxFiqWpAee0WIacR/JD3ZJ+PqjFb4yrQisTPsJoRyQf3IUJCdyRQbINRk9s Received: by 10.38.206.72 with SMTP id d72mr1286078rng; Tue, 19 Oct 2004 15:01:01 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 15:01:01 -0700 (PDT) Message-ID: <1f2ed5cd041019150129a2df2@mail.gmail.com> Date: Wed, 20 Oct 2004 00:01:01 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Bjoern Hoehrmann Subject: Re: IANA registry vs. URIs Cc: atom-syntax@imc.org In-Reply-To: <41d28574.403539348@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041019111221572a03@mail.gmail.com> <41cb6e8b.397675016@smtp.bjoern.hoehrmann.de> <1f2ed5cd041019141243df13a6@mail.gmail.com> <41d28574.403539348@smtp.bjoern.hoehrmann.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 23:48:15 +0200, Bjoern Hoehrmann wrote: > * Danny Ayers wrote: > >On Tue, 19 Oct 2004 21:50:31 +0200, Bjoern Hoehrmann wrote: > >> * Danny Ayers wrote: > >> >1. You can't take an IANA registered string and dereference it to find > >> >its meaning. > >> > >> Why not? > > > >Fair point. Try: "You can't take an arbitrary IANA registered string > >and dereference it using any well-known protocol it to find its > >meaning." > > Google is a well-known protocol to find out about everything of common > interest. Typing `http://example.org/atom/link-type/foo` rather than > `google atom link type foo` into the address bar of my browser does not > buy me much if anything. Nope, afraid you lost me there. > >> >Even if your comparison worked, then I would personally still prefer > >> >to see URIs used, because the registration barrier is high enough that > >> >I think people would simply tend to ignore it (like URI scheme > >> >registration). Whereas the barrier to using URIs is fairly low - > >> >domain name registration is relatively cheap. > >> > >> Why does this matter exactly? > > > >Standardization is useful for interoperability. > > Standardization by removing rules has an impact on interoperability? Standardization by selecting rules that stand a good chance of being followed has an impact on interoperability. Choosing rules that are likely to be broken is likely to be counter-productive. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 18:09:23 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 SAA20605 for ; Tue, 19 Oct 2004 18:09:22 -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 i9JM3N7a050192; Tue, 19 Oct 2004 15:03: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 i9JM3NgU050191; Tue, 19 Oct 2004 15:03:23 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JM3EVT050166; Tue, 19 Oct 2004 15:03:15 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd04101913596927164c@mail.gmail.com> References: <4175563D.7080603@franklinmint.fm> <1f2ed5cd041019111221572a03@mail.gmail.com> <20041019190656.29014.qmail@web41205.mail.yahoo.com> <41756452.3010604@franklinmint.fm> <1f2ed5cd04101913596927164c@mail.gmail.com> Date: Tue, 19 Oct 2004 15:03:15 -0700 To: Danny Ayers From: Paul Hoffman / IMC Subject: Re: IANA registry vs. URIs Cc: mint@franklinmint.fm, Dare Obasanjo , Atom WG 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:59 PM +0200 10/19/04, Danny Ayers wrote: >On Tue, 19 Oct 2004 12:28:47 -0700, Paul Hoffman / IMC > wrote: >> At 8:12 PM +0200 10/19/04, Danny Ayers wrote: >> >1. You can't take an IANA registered string and dereference it to find >> >its meaning. >> >> Of course not. You have to go look in the IANA registry. It's in a >> well-known and stable location that is relied on by every implementer >> of IETF protocols. > >The inability to dereference was one of your main arguments against >URIs. No, it was not. For one thing, I am not arguing against URIs: I am exposing the costs. The costs that I brough up are the inability to be sure you can dereference over a long period of time, and that what you get when you dereference later. There is a big difference between that and "inability to dereference". > I'm simply suggesting you apply the same criteria to both >options. I am doing so. IANA is a long-lived and stable repository; a URI is not necessarily. >On the other hand, you could set up a well-known location for finding >URI semantics (though I don't actually think that would be good >approach beyond informative docs). Sure; you could even call it IANA. :-) > > >2. If dereferencing was a necessary requirement of name definitions, >> >then anything that relied on XML Namespaces would fail to work. >> >> You're missing the point completely. Link *types* have some >> semantics. The URL that is used for the extension *of the type* is >> what tells you the semantics. > >Maybe I am missing the point, but as I understand the relevant >proposal (which I wrote) a URI will be used as an identifier for the >link type, in a similar way as an IANA-registered value would be. The >maintenance of the name is a separate issue from discovery of the >semantics of a particular type. OK, then I am misunderstanding your proposal. Assume that I'm implementing an Atom reader and I see a URL for a link type extension: where do I find the semantics for that link type? >There is considerable prior art in the use of URIs for typing >link-like constructs [1], [2], [3]. I'm not aware of any that have >found IANA registration necessary. None of those appear to use URIs for extending the list of types that can be used, it appears. Why did you bring those up? >I don't think it's strictly relevant, but discovery of the semantics >would probably be easier using a URI as it could /potentially/ be >deferenced (the spec could even mandate it) and standard techniques >such as RDDL, WSDL, RDF Schema and/or OWL used to provide semantics. ...which leads to the problems I brought up: URIs go away, and even when they don't go away, their content changes. >None of the IANA registries I've encountered have provided material in >a form that would be easy for an application to interpret. As I have said many times, we can say exactly how we want the IANA registry to behave. The fact that it hasn't been done doesn't means that we can't do it. >At 12:06 PM -0700 10/19/04, Dare Obasanjo wrote: >>Expecting an Atom reader to some how "learn" what to >>do with an ad-hoc link simply given a URI is venturing >>on AI. > >"learn"? >At it's most sophisticated I think we're talking about the reader >downloading a plugin. A plugin for what? We're talking about link *types* here. If I'm writing an Atom reader, I know what to do with the link and I don't need a plugin for it. However, I don't know how to present it to the user. >An Atom reader could fairly easily look up how to interpret an ad hoc >link type, it might even involve behaviour. At the URI? If not, where? And for how long will that work? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 19 18:13:33 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 SAA21298 for ; Tue, 19 Oct 2004 18:13:32 -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 i9JM86Kp051068; Tue, 19 Oct 2004 15:08: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 i9JM86W3051067; Tue, 19 Oct 2004 15:08:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JM85h6051039 for ; Tue, 19 Oct 2004 15:08:05 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail 14148 invoked by uid 65534); 19 Oct 2004 22:08:04 -0000 Received: from dsl-213-023-054-011.arcor-ip.net (EHLO voyager) (213.23.54.11) by mail.gmx.net (mp021) with SMTP; 20 Oct 2004 00:08:04 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: Atom Syntax Subject: Re: Options for link extensibility Date: Wed, 20 Oct 2004 00:07:55 +0200 Message-ID: <41d78ebb.405914353@smtp.bjoern.hoehrmann.de> References: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> In-Reply-To: <03AC65FE-2145-11D9-A19B-000A95A51C9E@sun.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * Tim Bray wrote: >How to do link extensibility: > >LE0 Don't: Atom has no abstract notion of a link. > >LE1 Hardwired: Itemize the different kinds of links in the Atom >specification. Extensibility requires a new version of the Atom >specification. > >LE2 Registry: The types of links are in a (presumably IANA) registry, >which can be extended using a well-understood process. > >LE3 URIs: Non-centralized extensibility is achieved by using URIs to >name types of links. I do not really understand these alternatives, is this about whether and how to allow people to put custom values into the rel attribute? Or is it about vs ? In particular the difference between LE0 and LE1 is not clear to me. From owner-atom-syntax@mail.imc.org Tue Oct 19 18:13:49 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 SAA21344 for ; Tue, 19 Oct 2004 18:13:48 -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 i9JM5lP6050651; Tue, 19 Oct 2004 15:05:47 -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 i9JM5lYb050650; Tue, 19 Oct 2004 15:05:47 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JM5k47050641 for ; Tue, 19 Oct 2004 15:05:46 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so169553rnb for ; Tue, 19 Oct 2004 15:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qWGTEQMLydo8JTnaWtaoalx2xuufi9ozIU2Rs1sIa7NMaYth5vEkPjNi4RmoBxI+etrY78tyu8OoRgVbKSLdMoPWeMEzY0E5pCCe4lgMGa8ljq7Tsalws1VuoIsimMGc6YspzroSxpsraT4KiNiKWu80bQBQPeUQgBLhUhKFcfg Received: by 10.38.206.72 with SMTP id d72mr1287832rng; Tue, 19 Oct 2004 15:05:51 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 15:05:51 -0700 (PDT) Message-ID: <1f2ed5cd04101915055ce48bb@mail.gmail.com> Date: Wed, 20 Oct 2004 00:05:51 +0200 From: Danny Ayers Reply-To: Danny Ayers To: bob@wyman.us Subject: Re: Article importance Cc: "Johan H. Borg" , "atom-syntax.imc.org" In-Reply-To: <200410192123.BVL72637@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410192123.BVL72637@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 17:23:23 -0400, Bob Wyman wrote: > Importance may tend to decay over time. Would you define > such a decay function? I believe the Knobot aggregator does just that: http://wymiwyg.org/knobot > It is best to think of Atom in terms of entries, not feeds. Remember > the slogan: "It's the Entries, Stupid!"... Yup. Probably the worst sounding but most useful slogan this century... -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 18: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 SAA22312 for ; Tue, 19 Oct 2004 18: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 i9JMCnio051940; Tue, 19 Oct 2004 15:12:49 -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 i9JMCm0N051938; Tue, 19 Oct 2004 15:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JMCmQD051928; Tue, 19 Oct 2004 15:12:48 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id E7AF24F415; Tue, 19 Oct 2004 18:12:50 -0400 (EDT) Message-Id: <6.0.0.20.2.20041020070732.04a6ca48@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 20 Oct 2004 07:08:15 +0900 To: Tim Bray , "Roy T. Fielding" From: Martin Duerst Subject: Re: IANA registry vs. URIs Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> References: <4175563D.7080603@franklinmint.fm> <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> Mime-Version: 1.0 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 At 06:29 04/10/20, Tim Bray wrote: > >On Oct 19, 2004, at 12:37 PM, Roy T. Fielding wrote: > >> The reasonable alternative is to make the field a URI-reference >> with a base URI equal to that of the IANA registry. That way, people >> who take the time to register a valuable name are rewarded with a >> short syntax, while the folks who want complete control of the >> specificity of their link types can mint their own URIs. Eventually, >> life will sort itself out and all of the significantly deployed types >> will become registered, and none of the insignificantly deployed >> types will collide with each other. > >I'll write up a Pace to formalize this proposal. It sounds uncluttered and sane to me. -Tim Great. I proposed something like this before, pointing to the input mode field in XForms. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Oct 19 18:21:27 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 SAA22448 for ; Tue, 19 Oct 2004 18:21:27 -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 i9JMDCuB052061; Tue, 19 Oct 2004 15:13: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 i9JMDCkA052060; Tue, 19 Oct 2004 15:13:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com ([66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JMDCFR051901 for ; Tue, 19 Oct 2004 15:13:12 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041019221232.87261.qmail@web41214.mail.yahoo.com> Received: from [131.107.71.225] by web41214.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 15:12:32 PDT Date: Tue, 19 Oct 2004 15:12:32 -0700 (PDT) From: Dare Obasanjo Subject: Re: IANA registry vs. URIs To: Danny Ayers , Paul Hoffman / IMC Cc: mint@franklinmint.fm, Atom WG In-Reply-To: <1f2ed5cd04101913596927164c@mail.gmail.com> 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: --- Danny Ayers wrote: > > > >Expecting an Atom reader to some how "learn" what > to > >do with an ad-hoc link simply given a URI is > venturing > >on AI. > > "learn"? > At it's most sophisticated I think we're talking > about the reader > downloading a plugin. > An Atom reader could fairly easily look up how to > interpret an ad hoc > link type, it might even involve behaviour. But I > think it would be a > stretch to call process/service identifiers AI. And my predictable answer is if all an application has to do is key off of some URI then know where to go to download the code to learn how to consume that URI then there is no difference between "link based extensibility" and "extensiblity based on extension elements in a third party namespace". Of course, this ignores the feasibility of actually implementing such a mechanism. Without a clear definition of what is meant to be a link then there is no difference between using link elements for extensibility and using arbitrarily structured extension elements for extensibility besides an arbitrary syntactic restriction. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Oct 19 18:25:04 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 SAA22705 for ; Tue, 19 Oct 2004 18: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 i9JMHmtv053437; Tue, 19 Oct 2004 15:17: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 i9JMHmdC053436; Tue, 19 Oct 2004 15:17:48 -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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JMHlK2053427 for ; Tue, 19 Oct 2004 15:17:48 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so170095rnb for ; Tue, 19 Oct 2004 15:17:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BwQM7Mb9yXP6JMvSTJhwXWvK26AfMgatZJK0MFc1GXH4Ucs2PHIyKMxFRZxj1gE7NZlOu6DGOqw/5rP6fFyqHRw0BZiDcW/w8gc9Lfi/atAktvqrz+8340NQZ36a8au98EQE32n7pc/1g7pfjtuOKXKJNUsNMtyIKbbFjy0SnNk Received: by 10.38.98.30 with SMTP id v30mr311364rnb; Tue, 19 Oct 2004 15:17:52 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 15:17:52 -0700 (PDT) Message-ID: <1f2ed5cd0410191517390fc957@mail.gmail.com> Date: Wed, 20 Oct 2004 00:17:52 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: IANA registry vs. URIs Cc: mint@franklinmint.fm, Dare Obasanjo , Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4175563D.7080603@franklinmint.fm> <1f2ed5cd041019111221572a03@mail.gmail.com> <20041019190656.29014.qmail@web41205.mail.yahoo.com> <41756452.3010604@franklinmint.fm> <1f2ed5cd04101913596927164c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 15:03:15 -0700, Paul Hoffman / IMC wrote: After all this, we may be talking at cross purposes - > A plugin for what? We're talking about link *types* here. If I'm > writing an Atom reader, I know what to do with the link and I don't > need a plugin for it. However, I don't know how to present it to the > user. Could you please provide a couple of simple examples, sorry, I've no idea what you mean. > >An Atom reader could fairly easily look up how to interpret an ad hoc > >link type, it might even involve behaviour. > > At the URI? If not, where? And for how long will that work? The URI identifies something. Using HTTP on it may give you an interpretation, or you may get that information through other means such as RDF Schema obtained from a repository. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 18:29: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 SAA23005 for ; Tue, 19 Oct 2004 18:29: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 i9JMO7Y3054535; Tue, 19 Oct 2004 15:24:07 -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 i9JMO7Yt054534; Tue, 19 Oct 2004 15:24:07 -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 i9JMO64Z054521; Tue, 19 Oct 2004 15:24:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CK2Oj-00063e-HJ; Tue, 19 Oct 2004 22:24:05 +0000 Message-ID: <4175940E.5000701@franklinmint.fm> Date: Tue, 19 Oct 2004 18:24:14 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Danny Ayers , Paul Hoffman / IMC , Atom WG Subject: Re: IANA registry vs. URIs References: <20041019221232.87261.qmail@web41214.mail.yahoo.com> In-Reply-To: <20041019221232.87261.qmail@web41214.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > > Without a clear definition of what is meant to be a > link... Do the approaches and working code outlined at the following URIs qualify as a "clear definition"? http://www.imc.org/atom-syntax/mail-archive/msg10669.html http://franklinmint.fm/2004/10/19/links.html Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 18:37:29 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 SAA23950 for ; Tue, 19 Oct 2004 18:37:29 -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 i9JMVfi2055760; Tue, 19 Oct 2004 15:31: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 i9JMVfRh055759; Tue, 19 Oct 2004 15:31:41 -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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JMVe6R055723 for ; Tue, 19 Oct 2004 15:31:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so170970rnb for ; Tue, 19 Oct 2004 15:31:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=b4iil+ljaIb6crAXoOrU0rV37M/EPyAx+Kw6tbMSthrSanR+J+GKFpQbKLMjAYMsUFef3zgH1AU+j8sWgz+F5WKTO6rhyPovfL32t0eQFXRKkVk8ZmbTYn6shUDIkzvRp97jd8trQrZfQKM7RvLvNZ82ob4SUEk73xDdBOyw3II Received: by 10.38.206.72 with SMTP id d72mr1297988rng; Tue, 19 Oct 2004 15:31:40 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 15:31:40 -0700 (PDT) Message-ID: <1f2ed5cd041019153125850f68@mail.gmail.com> Date: Wed, 20 Oct 2004 00:31:40 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: IANA registry vs. URIs Cc: Paul Hoffman / IMC , mint@franklinmint.fm, Atom WG In-Reply-To: <20041019221232.87261.qmail@web41214.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04101913596927164c@mail.gmail.com> <20041019221232.87261.qmail@web41214.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 15:12:32 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > > > >Expecting an Atom reader to some how "learn" what > > to > > >do with an ad-hoc link simply given a URI is > > venturing > > >on AI. > > > > "learn"? > > At it's most sophisticated I think we're talking > > about the reader > > downloading a plugin. > > An Atom reader could fairly easily look up how to > > interpret an ad hoc > > link type, it might even involve behaviour. But I > > think it would be a > > stretch to call process/service identifiers AI. > > And my predictable answer is if all an application has > to do is key off of some URI then know where to go to > download the code to learn how to consume that URI > then there is no difference between "link based > extensibility" and "extensiblity based on extension > elements in a third party namespace". There isn't all that much difference. The syntax restrictions of the link construct do signal that the app should treat this as a link construct, and identify the endpoints (subject and object) of the link relationship. But that could be in other ways. > Of course, this ignores the feasibility of actually > implementing such a mechanism. That would depend on what is expected of the implementation. > Without a clear definition of what is meant to be a > link then there is no difference between using link > elements for extensibility and using arbitrarily > structured extension elements for extensibility > besides an arbitrary syntactic restriction. True, but the definition could be anything from "a relationship between the feed and the remote URI" onwards. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 18:40:55 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 SAA24414 for ; Tue, 19 Oct 2004 18:40:54 -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 i9JMa2Hc056529; Tue, 19 Oct 2004 15:36: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 i9JMa2iv056528; Tue, 19 Oct 2004 15:36:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postal.verity.com ([192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JMa2lg056514 for ; Tue, 19 Oct 2004 15:36:02 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 5E7CBB3 for ; Tue, 19 Oct 2004 15:36:00 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9JMa0hc029238 for ; Tue, 19 Oct 2004 15:36:00 -0700 (PDT) Date: Tue, 19 Oct 2004 15:40:42 -0700 From: Walter Underwood To: Atom-Syntax Subject: Re: Time to add advertising to Atom? Message-ID: <8238DABF92C911904BDF2D63@diva.verity.com> In-Reply-To: References: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I believe that an advertising marker should be in the Atom core or in an extension published at the same time as the core. Some big reasons for this: 1. Publishers need advertising, so we can't pretend it won't exist. 2. Many ad channels (Google, for example) clearly mark ads for the user, so marked ads are acceptable to publishers. They may even be preferable, because they avoid some kinds of inadvertant deceptive advertising. 3. Automatic consumers(robots) need to be able to sort out the entries from the ads. Ads mised in with search results is just not acceptable to the users of search engines or profile services (pubsub.com). 4. A recommended place for advertising allows clients to push back on advertising in regular entries, links, whatever (spam). Also, it may be possible to apply anti-spam laws to advertising which is not properly marked. [No, I'm not a laywer or a legislator, but spam is everywhere and legal remedies are one current approach. Enabling those gives us more anti-spam weapons.] Some approaches: Ads as unmarked entries: This puts the responsibility entirely on the client. Welcome to the spam filtering business, again. Ads as marked entries: Good for robots, also allows clients to display a marker with the ads to distinguish them from other entries. Ads as non-entry items: We're having enough fun with entries. I can't imagine adding another kind of media content and getting it finished. Ads as links: Almost as complicated as a new kind of entry. An ad would need several coordinated links: an href, an optional image, text, etc. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Oct 19 18:48: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 SAA24917 for ; Tue, 19 Oct 2004 18:48:20 -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 i9JMhCUV057630; Tue, 19 Oct 2004 15:43: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 i9JMhC2Q057629; Tue, 19 Oct 2004 15:43:12 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JMhCSY057612 for ; Tue, 19 Oct 2004 15:43:12 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so171482rnb for ; Tue, 19 Oct 2004 15:43:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HhIlU0MPaOmtoQX8QF9iOe0htyo7h0rvSyGmfvXolnhXkIeUZdHdxhjVKGFjHM+XkLDjQerfaRWsVYIURohCHlb0odKuTnbtZ2IS30szjfY5R1vGPI4UKlNzQyDTYkWXSJHduax0FXjSW9Ii5+B8FDrxe2sxm0QPZYz2RnLCUrI Received: by 10.38.206.72 with SMTP id d72mr1302864rng; Tue, 19 Oct 2004 15:43:14 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 19 Oct 2004 15:43:14 -0700 (PDT) Message-ID: <1f2ed5cd04101915435e1acc80@mail.gmail.com> Date: Wed, 20 Oct 2004 00:43:14 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: Options for link extensibility Cc: Dare Obasanjo , Joe Gregorio , Tim Bray , Atom Syntax In-Reply-To: <41754D2A.3080808@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041019165913.97903.qmail@web41205.mail.yahoo.com> <41754D2A.3080808@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 13:21:46 -0400, Robert Sayre wrote: > > Dare Obasanjo wrote: > > > > In practical terms, I want a description good enough > > that I can write one chunk of code for dealing with > > elements and it can deal with all the link > > elements that may show up either from the Atom WG or > > as extensions in a consistent AND useful manner. > > > > OK. Let's examine the current practice. Here's what Mozilla does with > unknown link elements: > > http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/linkToolbarHandler.js#165 > > It ignores any link that contains a @rel value that includes: > > * stylesheet > * icon > * fontdef > * p3pv > * schema > > So, roughly, the resource pointed to by the link should be a standalone > resource that could replace the entry in a viewport, not information or > metadata related to policy or display of the entry. Which seems reasonable for a tool built around one big document-oriented viewport. One of the notable features of Atom (and RSS) is the way metadata is pushed into greater significance. Rather different. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 19 18:53: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 SAA25653 for ; Tue, 19 Oct 2004 18:53:13 -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 i9JMmEge058261; Tue, 19 Oct 2004 15:48:14 -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 i9JMmEHu058260; Tue, 19 Oct 2004 15:48:14 -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 i9JMmDNV058254 for ; Tue, 19 Oct 2004 15:48:13 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CK2m6-00022f-0p; Tue, 19 Oct 2004 22:48:14 +0000 Message-ID: <417599BC.6080008@franklinmint.fm> Date: Tue, 19 Oct 2004 18:48:28 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Dare Obasanjo , Joe Gregorio , Tim Bray , Atom Syntax Subject: Re: Options for link extensibility References: <20041019165913.97903.qmail@web41205.mail.yahoo.com> <41754D2A.3080808@franklinmint.fm> <1f2ed5cd04101915435e1acc80@mail.gmail.com> In-Reply-To: <1f2ed5cd04101915435e1acc80@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: >>So, roughly, the resource pointed to by the link should be a standalone >>resource that could replace the entry in a viewport, not information or >>metadata related to policy or display of the entry. > > > Which seems reasonable for a tool built around one big > document-oriented viewport. One of the notable features of Atom (and > RSS) is the way metadata is pushed into greater significance. Rather > different. So... what's your objection? Nothing is stopping you from creating some other element that has a URI in it. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 19:18:23 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 TAA29513 for ; Tue, 19 Oct 2004 19:18:22 -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 i9JNCYA5062673; Tue, 19 Oct 2004 16:12: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 i9JNCYBf062672; Tue, 19 Oct 2004 16:12:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao03.cox.net (fed1rmmtao03.cox.net [68.230.241.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JNCXEm062651; Tue, 19 Oct 2004 16:12:33 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao03.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041019231234.LGZL26841.fed1rmmtao03.cox.net@[192.168.0.100]>; Tue, 19 Oct 2004 19:12:34 -0400 In-Reply-To: <1f2ed5cd041019145049e49c35@mail.gmail.com> References: <4175563D.7080603@franklinmint.fm> <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> <1f2ed5cd041019145049e49c35@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5BDA6190-2224-11D9-99C1-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Tim Bray , Paul Hoffman / IMC , Atom WG From: "Roy T. Fielding" Subject: Re: IANA registry vs. URIs Date: Tue, 19 Oct 2004 16:12:33 -0700 To: Danny Ayers X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > What has actually been gained from the registration of the > significantly deployed types? Bits on the wire. They add up, quicker than you might imagine. Oh, and general happiness, since some people will violently oppose a method that is either only-IANA or only-URI. Removing any technical justification for their arguments brings world peace, so to speak. ....Roy From owner-atom-syntax@mail.imc.org Tue Oct 19 19:51:50 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 TAA03744 for ; Tue, 19 Oct 2004 19:51:49 -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 i9JNgdtV066701; Tue, 19 Oct 2004 16:42:39 -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 i9JNgdXU066700; Tue, 19 Oct 2004 16:42:39 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JNgbdn066694 for ; Tue, 19 Oct 2004 16:42:38 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <8238DABF92C911904BDF2D63@diva.verity.com> References: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> <8238DABF92C911904BDF2D63@diva.verity.com> Date: Tue, 19 Oct 2004 16:42:39 -0700 To: Atom-Syntax From: Paul Hoffman / IMC Subject: Re: Time to add advertising to Atom? 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 At 3:40 PM -0700 10/19/04, Walter Underwood wrote: >I believe that an advertising marker should be in the Atom core or in an >extension published at the same time as the core. This is not the core of the protocol. It's an add-on that someone thought up more than a year after people formulated what the core should be. Please feel free to write an extension, possibly with Asbjørn. When you have one that is reasonably well-baked, let the list know. Best of luck with the semantics of what an "advertisement" is..., much less what one isn't. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 19 19:56:59 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 TAA03988 for ; Tue, 19 Oct 2004 19:56:59 -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 i9JNo7m6067685; Tue, 19 Oct 2004 16:50:07 -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 i9JNo7W4067684; Tue, 19 Oct 2004 16:50:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JNo6uJ067654 for ; Tue, 19 Oct 2004 16:50:06 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 26992 messnum 5049545 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 19 Oct 2004 23:50:03 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail04.svc.cra.dublin.eircom.net (qp 26992) with SMTP; 19 Oct 2004 23:50:03 -0000 Message-ID: <4175A81C.1070004@dehora.net> Date: Wed, 20 Oct 2004 00:49:48 +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 WG Subject: Re: IANA registry vs. URIs References: 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: > > Wearing my co-chair and non-impelenter hats: > > The major difference between defining link type in an IANA registry or > by URI is interoperability. If something is in the IANA registry and we > have specified that you have to define what your registered type means, > then an implementer can look in the IANA registry and figure out what > this new link type means. They can't do that with a URI unless the URI > dereferences to a description of what the link type means. That's not true. > The assumption that many people are making here is that the > dereferencing will happen correctly for all time, and that the technical > content at the URI will not change. That's not an assumption I'm making. The dereference argument doesn't hold up imo. > The question comes down to: is the high interoperability value of having > a stable repository of definitions of link types worth the high cost of > commonly-used link types that lose their definitions plus the cost of > developers that don't bother to register at all? Historically in the > IETF, the answer to similar questions has been "yes", but we can > certainly answer that differently if we think the costs outweigh the > benefits of an IANA registry. For me, the issue with IANA v URis has to do with process. As for interop, neither URIs nor an IANA registry will of itself provide interop or consistent semantics for link typing; that is best supplied by a type system, whihc in turn implies we have a good abstraction for links. cheers Bill From owner-atom-syntax@mail.imc.org Tue Oct 19 20:02: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 UAA04345 for ; Tue, 19 Oct 2004 20:02:50 -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 i9JNrlnE068184; Tue, 19 Oct 2004 16:53:47 -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 i9JNrlKp068183; Tue, 19 Oct 2004 16:53:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JNrkAI068152 for ; Tue, 19 Oct 2004 16:53:46 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041019235347.7023.qmail@web41214.mail.yahoo.com> Received: from [131.107.71.94] by web41214.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 16:53:47 PDT Date: Tue, 19 Oct 2004 16:53:47 -0700 (PDT) From: Dare Obasanjo Subject: Re: IANA registry vs. URIs To: Robert Sayre Cc: Danny Ayers , Paul Hoffman / IMC , Atom WG In-Reply-To: <4175940E.5000701@franklinmint.fm> 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: --- Robert Sayre wrote: > > > > Without a clear definition of what is meant to be > a > > link... > > Do the approaches and working code outlined at the > following URIs > qualify as a "clear definition"? Nope. > http://www.imc.org/atom-syntax/mail-archive/msg10669.html This is a code sample in Javascript or some similar language using some object model I am not familiar with. That doesn't strike me as a clear definition of anything. > http://franklinmint.fm/2004/10/19/links.html The screenshot is better. So what is the definition of link the you suggest the Atom spec uses that ensures that whenever a client puts a rel value for a link in that drop down it is something that makes sense to the user? For example, if 'schema' and 'stylesheet' were handled in the same way I doubt most end users would find that useful. I read http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 and it contains a fairly straightforward definition of what it means to be a link. However this seems to conflict with the RDF-style extensibility Danny Ayers has been arguing for with his various posts on this thread and others. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Tue Oct 19 20:14: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 UAA05573 for ; Tue, 19 Oct 2004 20:14: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 i9K06xDe070038; Tue, 19 Oct 2004 17:06:59 -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 i9K06xO2070037; Tue, 19 Oct 2004 17:06:59 -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 i9K06wCW069975; Tue, 19 Oct 2004 17:06:59 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CK40G-0007ud-SG; Wed, 20 Oct 2004 00:06:56 +0000 Message-ID: <4175AC2F.9060306@franklinmint.fm> Date: Tue, 19 Oct 2004 20:07:11 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: Danny Ayers , Paul Hoffman / IMC , Atom WG Subject: Re: IANA registry vs. URIs References: <20041019235347.7023.qmail@web41214.mail.yahoo.com> In-Reply-To: <20041019235347.7023.qmail@web41214.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > --- Robert Sayre wrote: > > >>>Without a clear definition of what is meant to be >> >>a >> >>>link... >> >>Do the approaches and working code outlined at the >>following URIs >>qualify as a "clear definition"? > > > Nope. > > > http://www.imc.org/atom-syntax/mail-archive/msg10669.html > > This is a code sample in Javascript or some similar > language using some object model I am not familiar > with. That doesn't strike me as a clear definition of > anything. > > >>http://franklinmint.fm/2004/10/19/links.html > > > The screenshot is better. So what is the definition of > link the you suggest the Atom spec uses that ensures > that whenever a client puts a rel value for a link in > that drop down it is something that makes sense to the > user? For example, if 'schema' and 'stylesheet' were > handled in the same way I doubt most end users would > find that useful. No spec can guarantee that every rel value will be useful to every end user. For example, there's nothing stopping me from linking a P3P file in an HTML anchor. What the spec can do is outline what is for. > > I read > http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 > and it contains a fairly straightforward definition of > what it means to be a link. So if we adopt that definition, you're ok with that? > However this seems to > conflict with the RDF-style extensibility Danny Ayers > has been arguing for with his various posts on this > thread and others. PaceMetaElement? Robert Sayre From owner-atom-syntax@mail.imc.org Tue Oct 19 20:16:23 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 UAA05649 for ; Tue, 19 Oct 2004 20:16:23 -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 i9K09LZj070442; Tue, 19 Oct 2004 17:09: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 i9K09Lf8070441; Tue, 19 Oct 2004 17:09:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K09FOe070426 for ; Tue, 19 Oct 2004 17:09:16 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 20 Oct 2004 10:09:28 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Oct 2004 10:09:18 +1000 Subject: Re: IANA registry vs. URIs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4175A81C.1070004@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9K09KOe070436 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 20/10/04 9:49 AM, "Bill de hÓra" wrote: >> The assumption that many people are making here is that the >> dereferencing will happen correctly for all time, and that the technical >> content at the URI will not change. > > That's not an assumption I'm making. The dereference argument > doesn't hold up imo. The 'dereferencing' argument isn't really about actual dereferencing. It's about finding information which describes what that link type means. Trees vs forest. With an IANA registry, it's possible to find what a given registered link type is, who registered it, references to documentation, descriptions of semantics and use, descriptions of limitations/restrictions, etc. All assuming we set up the registry for this of course, as distinct from a really simple registration that only lists the link type tokens and nothing else. With URI based link types there is only one place to look to find information, and that place may be broken. You could try querying google with the domain name of the URI and other bits of the URI ... good luck with that though since google will only tell you what it knows, not what it doesn't[1], and with what it does know it biases heavily towards what is popular rather than authoritative. e. [1] I receive google alerts each week for content it finds each day with keywords of interest to me, and while it does send me links to new websites it is also only just now discovering some web pages which date back to 1997. From owner-atom-syntax@mail.imc.org Tue Oct 19 20:18: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 UAA05856 for ; Tue, 19 Oct 2004 20:18:45 -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 i9K0AM2Q070542; Tue, 19 Oct 2004 17:10:22 -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 i9K0AL5r070541; Tue, 19 Oct 2004 17:10:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K0AKmx070534 for ; Tue, 19 Oct 2004 17:10:21 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 20 Oct 2004 10:10:34 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Oct 2004 10:10:25 +1000 Subject: Re: IANA registry vs. URIs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4175A81C.1070004@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9K0ALmx070535 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 20/10/04 9:49 AM, "Bill de hÓra" wrote: > which in turn implies we have a good > abstraction for links. does anyone object to us working towards that goal then? e. From owner-atom-syntax@mail.imc.org Tue Oct 19 20:28:38 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 UAA06887 for ; Tue, 19 Oct 2004 20:28:38 -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 i9K0K93X071757; Tue, 19 Oct 2004 17:20:09 -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 i9K0K97d071756; Tue, 19 Oct 2004 17:20:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K0K87Q071749 for ; Tue, 19 Oct 2004 17:20:09 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 20 Oct 2004 10:20:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Oct 2004 10:20:13 +1000 Subject: Re: IANA registry vs. URIs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041019235347.7023.qmail@web41214.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20/10/04 9:53 AM, "Dare Obasanjo" wrote: > I read http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 and it > contains a fairly straightforward definition of what it means to be a link. > While PaceLinkPurpose is not perfect, is it heading in the right direction? How can we fix PaceLinkPurpose to more clearly define this style (traversal) of link? > However this seems to conflict with the RDF-style extensibility Danny Ayers > has been arguing for with his various posts on this thread and others. I just took a quick look at PaceMetaElement, thinking it would be the sister to PaceServiceElement in the context of PaceLinkPurpose. My bad ... sheesh, that proposed syntax is scarily perverse (sorry!). Again, how can we fix PaceMetaElement to more clearly define this style (metadata) of link? e. From owner-atom-syntax@mail.imc.org Wed Oct 20 03:37:09 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 DAA07799 for ; Wed, 20 Oct 2004 03:37:08 -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 i9K7RLuX079369; Wed, 20 Oct 2004 00:27: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 i9K7RLDZ079368; Wed, 20 Oct 2004 00:27:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K7RLoI079359 for ; Wed, 20 Oct 2004 00:27:21 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 81843 invoked by uid 17064); 20 Oct 2004 07:27:21 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.136.235]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 20 Oct 2004 07:27:21 -0000 In-Reply-To: <200410192026.BVL52159@ms8.netsolmail.com> References: <200410192026.BVL52159@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78722BEE-2269-11D9-894C-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: " " From: Henry Story Subject: Re: Bell on Standards Date: Wed, 20 Oct 2004 09:27:17 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks for pointing this out. I had failed to make the link between the name and the person. I retract that statement, and will go and study the article a lot more carefully. Henry Story On 19 Oct 2004, at 22:26, Bob Wyman wrote: > > Henry Story wrote: >> But then Gordon Bell is working for Microsoft, so this blindness >> is not so surprising. > This sort of libel has no place in this group. Your cheap shot at > Gordon Bell merely proves that you have no idea of the man's > contribution to > this industry -- long before Microsoft decided to fund his > retirement... > If Bell fails to praise Unix it is probably because he remembers the > long years during which Unix offered little more than pipes as the > solution > to all issues of componentization. Gordon Bell, on the other hand, led > the > development efforts at Digital that resulted in such innovations as the > Common Runtime Library for all languages on VMS, shared libraries, > common > calling standards, layered product architectures, etc. that were the > real > introducers of the idea of componentization to the software world. > But, one > would have to understand and care about history in order to know these > things and many others... Unfortunately, understanding history takes > much > more effort then the cheap shot you delivered. > > bob wyman > > From owner-atom-syntax@mail.imc.org Wed Oct 20 03:46: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 DAA08274 for ; Wed, 20 Oct 2004 03:46: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 i9K7cle5084179; Wed, 20 Oct 2004 00:38:47 -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 i9K7clFj084178; Wed, 20 Oct 2004 00:38:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K7cjnk083962 for ; Wed, 20 Oct 2004 00:38:46 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 20 Oct 2004 17:38:23 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Oct 2004 17:38:13 +1000 Subject: Re: IANA registry vs. URIs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41d28574.403539348@smtp.bjoern.hoehrmann.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20/10/04 7:48 AM, "Bjoern Hoehrmann" wrote: > Google is a well-known protocol to find out about everything of common > interest. Typing `http://example.org/atom/link-type/foo` rather than > `google atom link type foo` into the address bar of my browser does not > buy me much if anything. In October of 1999 I wrote an email to a public mailing list concerning Lotus, Microsoft, and AOL preparing IM for the enterprise. I referenced a CHI 99 paper by Tom Erickson in which he refers to "Socially Translucent Systems". That term is explicitly mentioned in the email. That email message was archived onto the web in October 1999. Find it in google, if you can. Can't be that many web pages with that particular constellation of keywords. Once you've tried that, I'll tell you the URL in question. You can then pump that URL into google and try clicking the three options it offers... Find web pages that are similar to ... Find web pages that link to ... Find web pages that contain the term ... ... and google will tell you that it knows absolutely nothing about that URL. Zero, zip, nada. Y'know, I learned a long time ago that just because someone talks fast it doesn't mean they have all the answers. Google is capable of talking fast, very fast, regurgitating what it knows about 4,285,199,774 web pages ... doesn't mean it has the answers to what I want. e. From owner-atom-syntax@mail.imc.org Wed Oct 20 07:40: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 HAA24033 for ; Wed, 20 Oct 2004 07:40: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 i9KBUBjb090592; Wed, 20 Oct 2004 04:30:11 -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 i9KBUBMu090591; Wed, 20 Oct 2004 04:30:11 -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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KBU9Ix090556 for ; Wed, 20 Oct 2004 04:30:10 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so195716rnb for ; Wed, 20 Oct 2004 04:30:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=DZSrliOnl7isFF2srmR9w6gdOWTDA7pCgTXDEYrOZ2LFi3nf3gCUh0UUstOvJFgbOzRjDqTZUEDjZWqGDXqdYKSgzjxhGdhhwWhpYCNoSI1S9lTh4kzhnbthRGWN6l+8Oq05iMeBqyvNncRCLYIlQwBbOM/2gJa1+p+ymUWKIOg Received: by 10.38.179.56 with SMTP id b56mr1494548rnf; Wed, 20 Oct 2004 04:30:05 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 20 Oct 2004 04:30:05 -0700 (PDT) Message-ID: <1f2ed5cd04102004301f77cbbd@mail.gmail.com> Date: Wed, 20 Oct 2004 13:30:05 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: Options for link extensibility Cc: Dare Obasanjo , Joe Gregorio , Tim Bray , Atom Syntax In-Reply-To: <417599BC.6080008@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041019165913.97903.qmail@web41205.mail.yahoo.com> <41754D2A.3080808@franklinmint.fm> <1f2ed5cd04101915435e1acc80@mail.gmail.com> <417599BC.6080008@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 18:48:28 -0400, Robert Sayre wrote: > Danny Ayers wrote: > > >>So, roughly, the resource pointed to by the link should be a standalone > >>resource that could replace the entry in a viewport, not information or > >>metadata related to policy or display of the entry. > > > > > > Which seems reasonable for a tool built around one big > > document-oriented viewport. One of the notable features of Atom (and > > RSS) is the way metadata is pushed into greater significance. Rather > > different. > > So... what's your objection? Nothing is stopping you from creating some > other element that has a URI in it. Sure, and hopefully I'll have time to be Pace-oriented later in the day. I'm just suggesting that the way Mozilla uses HTML's may not be a good basis for Atom's , for two main reasons - 1. the link element in HTML in use has more than one nature, in particular, aside from viewport material it has: * stylesheet * icon * fontdef * p3pv * schema (all ignored by Moz) 2. that Atom applications differ from HTML applications in a way that cuts right through - the content/metadata balance Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 20 07:54: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 HAA25129 for ; Wed, 20 Oct 2004 07:54:13 -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 i9KBlYsf094521; Wed, 20 Oct 2004 04:47: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 i9KBlYkX094520; Wed, 20 Oct 2004 04:47:34 -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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KBlXTw094512 for ; Wed, 20 Oct 2004 04:47:33 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so196208rnb for ; Wed, 20 Oct 2004 04:47:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GS0X+PiGmBofUPwctDCAj5rBHBARB+g8Rl32H3svslAkkltgvQUSDjAZyM3G72w17TvaG70XbABMXL8h31l6dTSlLGQLdmO3Z2hvF187ie6zf+T54vqZbSihTV0I0ePWCryrGCK4JI3f3Gq1a0OnR4HIjY8fTCVG4JZNg9QXRzI Received: by 10.38.206.72 with SMTP id d72mr1551706rng; Wed, 20 Oct 2004 04:47:32 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 20 Oct 2004 04:47:32 -0700 (PDT) Message-ID: <1f2ed5cd041020044755c5fc2a@mail.gmail.com> Date: Wed, 20 Oct 2004 13:47:32 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: IANA registry vs. URIs Cc: Robert Sayre , Paul Hoffman / IMC , Atom WG In-Reply-To: <20041019235347.7023.qmail@web41214.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4175940E.5000701@franklinmint.fm> <20041019235347.7023.qmail@web41214.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 16:53:47 -0700 (PDT), Dare Obasanjo wrote: > I read > http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 > and it contains a fairly straightforward definition of > what it means to be a link. However this seems to > conflict with the RDF-style extensibility Danny Ayers > has been arguing for with his various posts on this > thread and others. Just for the record, I was strongly in favour of using the element as a point of extension firstly because the list of @rel values was growing over time, and secondly as the mechanism would cover a significant part of the structured extensibility RSS 1.0 gains from RDF. If is refactored as has been discussed ( etc), and there are other routes to extensibility under discussion, I don't really have any major objection to what remains being HTML--like. I'm still not sure it's entirely appropriate, as Atom is more data-oriented (for want of a better divide) that HTML, so the doc-oriented usage in Moz doesn't seem to mesh well. But what's left of this issue is at its heart only about element naming, not a big deal. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 20 08:11:07 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 IAA26193 for ; Wed, 20 Oct 2004 08:11:05 -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 i9KC0WBi097954; Wed, 20 Oct 2004 05:00: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 i9KC0W7P097953; Wed, 20 Oct 2004 05:00:32 -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 ESMTP id i9KC0V9A097937 for ; Wed, 20 Oct 2004 05:00:31 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so196469rnb for ; Wed, 20 Oct 2004 05:00:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=safhYoE2mFxrRUkdekX/IMrWW7ZNEUkdictwzSX7YLZDdBJNCl+w9vyxfVwyyo2/RSJbLWWAZVPmEXzkE5RsOoL6q0Y/VQvCE4D97Fojfjnqy3y69IL7eOrFGtxd3p/PbwYg/r/gylYpgkbS1IxHV2b3OWp194r9KkY8pJKJKE4 Received: by 10.38.98.30 with SMTP id v30mr572424rnb; Wed, 20 Oct 2004 05:00:28 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 20 Oct 2004 05:00:28 -0700 (PDT) Message-ID: <1f2ed5cd041020050017d3f4f4@mail.gmail.com> Date: Wed, 20 Oct 2004 14:00:28 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: IANA registry vs. URIs Cc: Dare Obasanjo , Paul Hoffman / IMC , Atom WG In-Reply-To: <4175AC2F.9060306@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041019235347.7023.qmail@web41214.mail.yahoo.com> <4175AC2F.9060306@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 20:07:11 -0400, Robert Sayre wrote: > PaceMetaElement? After RDF/XML was taken off the table early on, that kind of approach did appeal to me (see [1]). It does have a precedent in HTML, SVG etc etc. But I've come to the view that it's altogether an ugly approach, as it's adding an extra layer where there doesn't need to be one. The elements within an are descriptions of the entry, it's already meta. So I'd favour something more along the lines of the structural relationships discussed (but never Pace'd) a week or so ago (must find...) Cheers, Danny. [1] http://www.intertwingly.net/wiki/pie/SyntaxExtensionMechanism -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 20 08:15:04 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 IAA26592 for ; Wed, 20 Oct 2004 08:15: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 i9KC5igF098565; Wed, 20 Oct 2004 05:05: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 i9KC5iVU098564; Wed, 20 Oct 2004 05:05:44 -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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KC5hrH098552 for ; Wed, 20 Oct 2004 05:05:43 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so196604rnb for ; Wed, 20 Oct 2004 05:05:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=sNVo+UoBsbCuW4anIn8lQa/9cDzcH1tfXwyt8tJQ+ZlLCwN7zm/jNVGeEeG0KOw1TVehydQ0k9BAwlYOQvaqYKS9HgEFpRLpcH8Tv7a7gjyg4pI544cyO3w7bVbbOkdWxry8GwIN34/l/ZOE9lY+D2+Yin1O3uN7wc/0OfJMz64 Received: by 10.38.206.72 with SMTP id d72mr1557658rng; Wed, 20 Oct 2004 05:05:45 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 20 Oct 2004 05:05:44 -0700 (PDT) Message-ID: <1f2ed5cd041020050548224ce@mail.gmail.com> Date: Wed, 20 Oct 2004 14:05:44 +0200 From: Danny Ayers Reply-To: Danny Ayers To: "Roy T. Fielding" Subject: Re: IANA registry vs. URIs Cc: Tim Bray , Paul Hoffman / IMC , Atom WG In-Reply-To: <5BDA6190-2224-11D9-99C1-000393753936@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4175563D.7080603@franklinmint.fm> <5BF76A10-2206-11D9-8A83-000393753936@gbiv.com> <04F05871-2216-11D9-A19B-000A95A51C9E@sun.com> <1f2ed5cd041019145049e49c35@mail.gmail.com> <5BDA6190-2224-11D9-99C1-000393753936@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 19 Oct 2004 16:12:33 -0700, Roy T. Fielding wrote: > > What has actually been gained from the registration of the > > significantly deployed types? > > Bits on the wire. They add up, quicker than you might imagine. I don't see a cause and effect there... > Oh, and general happiness, since some people will violently oppose > a method that is either only-IANA or only-URI. Removing any technical > justification for their arguments brings world peace, so to speak. ...but I can't argue with that. Cheers, Danny. From owner-atom-syntax@mail.imc.org Wed Oct 20 08:34: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 IAA27606 for ; Wed, 20 Oct 2004 08:34:29 -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 i9KCPUwA003926; Wed, 20 Oct 2004 05:25:30 -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 i9KCPUYO003925; Wed, 20 Oct 2004 05:25:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf28.cluster1.charter.net (mxsf28.cluster1.charter.net [209.225.28.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KCPToB003879 for ; Wed, 20 Oct 2004 05:25:29 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from mxip03.cluster1.charter.net (mxip03a.cluster1.charter.net [209.225.28.133]) by mxsf28.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i9KCPNga004376 for ; Wed, 20 Oct 2004 08:25:23 -0400 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip03.cluster1.charter.net with ESMTP; 20 Oct 2004 08:25:18 -0400 X-Ironport-AV: i="3.85,154,1094443200"; d="scan'208"; a="366303663:sNHT27528264" Received: from ndw by localhost with local (Exim 3.36 #1 (Debian)) id 1CKFWk-00013b-00 for ; Wed, 20 Oct 2004 08:25:14 -0400 To: Atom Syntax Subject: Re: atom:link state of play References: From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 20 Oct 2004 08:25:13 -0400 In-Reply-To: (Tim Bray's message of "Thu, 14 Oct 2004 10:30:28 -0700") Message-ID: <87brexo9ue.fsf@nwalsh.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain [ I've had my eye off this particular ball for a few weeks (to the tune of 750 or so messages that I've got no hope of properly catching up on). I guess that's a warning to assume I'm a little clueless. ] / Tim Bray was heard to say: | On Oct 13, 2004, at 7:49 PM, Paul Hoffman / IMC wrote: | |> Would you (and others) be happy with a simple IANA registry that |> gets filled in when there is a standards-track RFC. It would start |> with "alternate -> RFC {ournumber}", and entries would be added as |> the RFCs issued. FWIW, it would be perfectly permissible for a |> single RFC to be the registration for multiple new values. | | I could go for this, only the registry should have more than one | initial value. I would ruthlessly refuse any "would-be-nice" values | and accept only things that have been very widely deployed and used | already . | | Specifically: "alternate", "about", and "attachment". | | And if we *can't* get consensus on this list, I say the hell with it, | just have an with no @rel, used for what we now call | rel='alternate', and leave the rest for extensions. -Tim That looks attractive to me. Let the community build a few extension vocabularies, see which ones catch on, see what semantics turn out to be useful "in the wild" and then decide what to standardize. Be seeing you, norm -- Norman Walsh | Where are you dying tonight?--Evelyn http://nwalsh.com/ | Waugh --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBdlkpOyltUcwYWjsRAioLAKCnOV4rR6FVBoRhiLCmnN8qBGidwACgsXtI 6rfCGe58fD/UciGZ4/BJyZg= =OPOF -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Oct 20 08:35: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 IAA27687 for ; Wed, 20 Oct 2004 08:35: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 i9KCSdF9004762; Wed, 20 Oct 2004 05:28:39 -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 i9KCSdwo004761; Wed, 20 Oct 2004 05:28:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf14.cluster1.charter.net (mxsf14.cluster1.charter.net [209.225.28.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KCSbTr004739 for ; Wed, 20 Oct 2004 05:28:38 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from mxip01.cluster1.charter.net (mxip01a.cluster1.charter.net [209.225.28.131]) by mxsf14.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i9KCSQ97013856 for ; Wed, 20 Oct 2004 08:28:33 -0400 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip01.cluster1.charter.net with ESMTP; 20 Oct 2004 08:28:26 -0400 X-Ironport-AV: i="3.85,154,1094443200"; d="scan'208"; a="334303558:sNHT31795438" Received: from ndw by localhost with local (Exim 3.36 #1 (Debian)) id 1CKFZi-000186-00 for ; Wed, 20 Oct 2004 08:28:18 -0400 To: Atom Syntax Subject: Re: Time to add advertising to Atom? References: <20041018191706.54785.qmail@web41203.mail.yahoo.com> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Wed, 20 Oct 2004 08:28:18 -0400 In-Reply-To: <20041018191706.54785.qmail@web41203.mail.yahoo.com> (Dare Obasanjo's message of "Mon, 18 Oct 2004 12:17:06 -0700 (PDT)") Message-ID: <877jplo9p9.fsf@nwalsh.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable / Dare Obasanjo was heard to say: | --- Asbj=C3=B8rn Ulsberg wrote: | |>=20 |> I mean, if most clients don't support this |> extension, the ad agencies will=20=20 |> clutter and destroy Atom (and RSS before that) with |> their own additions=20=20 |> that indubitably _will_ be supported by as good as |> all clients. They won't=20=20 |> hear about optional extensions supported by 5% of |> the client mass and in=20=20 |> that group, everyone can turn it off whenever they |> want. | | Why would any client want to explicitly support a | mechanism for shoving ads in users faces regardless of | whether it is in an extension or a 'mandatory' part of | Atom?=20 Indeed. The sole value I can think of for standarization is that clients would know what content to suppress with extreme prejudice. Maybe that's a really, really good reason to sandardize it :-) Be seeing you, norm =2D-=20 Norman Walsh | Society is immoral and immortal; it can http://nwalsh.com/ | afford to commit any kind of folly, and | indulge in any kind of vice; it cannot | be killed, and the fragments that | survive can always laugh at the | dead.--Henry Adams --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBdlniOyltUcwYWjsRArAOAJ9aCQNU74HYVkRHXeMm4WM+QDM+eQCfVX2J auWqe1SPwTIQZc00z63tapo= =BGPq -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Wed Oct 20 10:08:22 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 KAA04870 for ; Wed, 20 Oct 2004 10:08: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 i9KDwd84028399; Wed, 20 Oct 2004 06:58:39 -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 i9KDwd36028398; Wed, 20 Oct 2004 06:58:39 -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 i9KDwdUl028382 for ; Wed, 20 Oct 2004 06:58:39 -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 <20041020135835014004q7ume>; Wed, 20 Oct 2004 13:58:36 +0000 Date: Wed, 20 Oct 2004 07:58:34 -0600 Subject: Re: IANA registry vs. URIs 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: <1f2ed5cd041020044755c5fc2a@mail.gmail.com> Message-Id: <2219EB74-22A0-11D9-9F3F-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, October 20, 2004, at 05:47 AM, Danny Ayers wrote: > If is refactored as has been discussed ( etc), and > there are other routes to extensibility under discussion, I don't > really have any major objection to what remains being > HTML--like. > > I'm still not sure it's entirely appropriate, as Atom is more > data-oriented (for want of a better divide) that HTML, so the > doc-oriented usage in Moz doesn't seem to mesh well. But what's left > of this issue is at its heart only about element naming, not a big > deal. > The Mozilla approach shows exactly what I'd like to see applications able to do with , the difference being that in the case of Atom, the spec should be where things like stylesheets are removed from the list. In other words, "stylesheet" et al should not be allowed into @rel. Allow me to repeat in this context what I've said on this subject before. In most cases, webmasters don't link to stylesheets so that people can see the stylesheet, but so that browsers will format the webpage based on it. When they DO want people to SEE the stylesheet, they link to it with , not with . In the same way, Atom publishers should only put things into that they want people to be able to traverse a link directly to. This could include another feed, perhaps an atom:entry (if we decide an entry can be a document element), a webpage, a particular anchor within a webpage, a PDF file, a JPEG image, etc. A JPEG image is another example of where it is the publisher's intention that governs whether to use or some other mechanism. In some cases, the publisher intends for an image to be displayed within a webpage. In those cases they use . In other cases, they intend it to be displayed by itsself. In those cases, they use . as with stylesheets, is for the case, not the case. Whatever spec text we come up with to define what an atom:link is, perhaps a PROSE example or two like the above discussion of stylesheets and images would be advantageous, just to be sure that people understand. I'll have to think on some language for PaceLinkPurpose based on the above... From owner-atom-syntax@mail.imc.org Wed Oct 20 10:48: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 KAA11329 for ; Wed, 20 Oct 2004 10:48: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 i9KEbbWS038182; Wed, 20 Oct 2004 07:37:37 -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 i9KEbbmY038181; Wed, 20 Oct 2004 07:37:37 -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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KEbaZk038167 for ; Wed, 20 Oct 2004 07:37:36 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so204403rnb for ; Wed, 20 Oct 2004 07:37:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=SmO65XzTJ99YFUPPvgabFBfzDhLZ+5srzhcRXq19oslhc3Q9L1BjndlMfcHdTh4LnlHtT6Y6Dh690gRGnaD1A349jDPZNWeUeDAC+y+8oMX3xbMZDRN7DKrODVslwT6auKHzpFivtMBGG4Vs/dBdSLo2AgbN3LKwsMb7XMdPklE Received: by 10.38.206.72 with SMTP id d72mr1620169rng; Wed, 20 Oct 2004 07:37:38 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Wed, 20 Oct 2004 07:37:37 -0700 (PDT) Message-ID: <1f2ed5cd0410200737ba6dfe8@mail.gmail.com> Date: Wed, 20 Oct 2004 16:37:37 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Antone Roundy Subject: Re: IANA registry vs. URIs Cc: atom-syntax@imc.org In-Reply-To: <2219EB74-22A0-11D9-9F3F-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041020044755c5fc2a@mail.gmail.com> <2219EB74-22A0-11D9-9F3F-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Quick practical questions on this approach. Let's say the linked information is an XSLT-transformed version of the feed, say into docbook format. feed is at http://example.org/feed.atom stylesheet at http://example.org/atom2docbook.xsl How would you express that? What do you think a typical client might display, and what behaviour might be available? Now say you want to say that a particular entry is associated with a particular category in a remotely-defined scheme. scheme: http://www.flickr.com category: http://www.flickr.com/photos/tags/kitten/ Again, how would you express that? What do you think a typical client might display, and what behaviour might be available? Cheers, Danny. On Wed, 20 Oct 2004 07:58:34 -0600, Antone Roundy wrote: > > On Wednesday, October 20, 2004, at 05:47 AM, Danny Ayers wrote: > > If is refactored as has been discussed ( etc), and > > there are other routes to extensibility under discussion, I don't > > really have any major objection to what remains being > > HTML--like. > > > > I'm still not sure it's entirely appropriate, as Atom is more > > data-oriented (for want of a better divide) that HTML, so the > > doc-oriented usage in Moz doesn't seem to mesh well. But what's left > > of this issue is at its heart only about element naming, not a big > > deal. > > > The Mozilla approach shows exactly what I'd like to see applications > able to do with , the difference being that in the case of Atom, > the spec should be where things like stylesheets are removed from the > list. In other words, "stylesheet" et al should not be allowed into > @rel. Allow me to repeat in this context what I've said on this > subject before. > > In most cases, webmasters don't link to stylesheets so that people can > see the stylesheet, but so that browsers will format the webpage based > on it. When they DO want people to SEE the stylesheet, they link to it > with , not with . In the same way, Atom publishers should > only put things into that they want people to be able to > traverse a link directly to. This could include another feed, perhaps > an atom:entry (if we decide an entry can be a document element), a > webpage, a particular anchor within a webpage, a PDF file, a JPEG > image, etc. A JPEG image is another example of where it is the > publisher's intention that governs whether to use or some > other mechanism. In some cases, the publisher intends for an image to > be displayed within a webpage. In those cases they use . In > other cases, they intend it to be displayed by itsself. In those > cases, they use . as with stylesheets, is for the > case, not the case. > > Whatever spec text we come up with to define what an atom:link is, > perhaps a PROSE example or two like the above discussion of stylesheets > and images would be advantageous, just to be sure that people > understand. I'll have to think on some language for PaceLinkPurpose > based on the above... > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Oct 20 11:44: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 LAA16063 for ; Wed, 20 Oct 2004 11:44: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 i9KFYWJL052995; Wed, 20 Oct 2004 08:34: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 i9KFYWBH052994; Wed, 20 Oct 2004 08:34:32 -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 i9KFYUii052966 for ; Wed, 20 Oct 2004 08:34:31 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CKITg-0003ms-NG; Wed, 20 Oct 2004 15:34:16 +0000 Message-ID: <41768586.5040405@franklinmint.fm> Date: Wed, 20 Oct 2004 11:34:30 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Antone Roundy , atom-syntax@imc.org Subject: Re: IANA registry vs. URIs References: <1f2ed5cd041020044755c5fc2a@mail.gmail.com> <2219EB74-22A0-11D9-9F3F-003065EA6144@geckotribe.com> <1f2ed5cd0410200737ba6dfe8@mail.gmail.com> In-Reply-To: <1f2ed5cd0410200737ba6dfe8@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > Quick practical questions on this approach. Let's say the linked > information is an XSLT-transformed version of the feed, say into > docbook format. > What's the URI of the XSLT-transformed version? > scheme: http://www.flickr.com > category: http://www.flickr.com/photos/tags/kitten/ > > Again, how would you express that? > What do you think a typical client might display, and what behaviour > might be available? Some other tag. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Oct 20 11:46:19 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 LAA16341 for ; Wed, 20 Oct 2004 11:46: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 i9KFcXKE054075; Wed, 20 Oct 2004 08:38: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 i9KFcXUY054074; Wed, 20 Oct 2004 08:38:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KFcXeD054051 for ; Wed, 20 Oct 2004 08:38:33 -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 (sccrmhc12) with SMTP id <2004102015382901200fu5vbe>; Wed, 20 Oct 2004 15:38:29 +0000 Date: Wed, 20 Oct 2004 09:38:28 -0600 Subject: Re: IANA registry vs. URIs Content-Type: text/plain; delsp=yes; 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: <1f2ed5cd0410200737ba6dfe8@mail.gmail.com> Message-Id: <168BCFB8-22AE-11D9-9F3F-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, October 20, 2004, at 08:37 AM, Danny Ayers wrote: > Quick practical questions on this approach. Let's say the linked > information is an XSLT-transformed version of the feed, say into > docbook format. > > feed is at http://example.org/feed.atom > stylesheet at http://example.org/atom2docbook.xsl > > How would you express that? > What do you think a typical client might display, and what behaviour > might be available? Solution A: Use some other element--"you can tranform my parent to such-and-such type using such-and-such stylesheet": . ...or "you can tranform the thing pointed to by @href to such-and-such type using such-and-such stylesheet": Solution B: Link to an external service that does such transformations: Solution C: Amend atom:link to do it as follows (This would be slightly weird if linking to a transformation of oneself, because what would you put into @rel? "alternate"? Until one of the tranformations was applied, it wouldn't be an alternate--it would be more like "self".): Solution D: Amend atom:link to do it as follows (in this case @type is the type AFTER the transformation, or you'd have to add yet another attribute like target-type="..."): The question is, how important is it to support this in the core? Should atom:link be burdened with this? Should some other core element handle it? Should Atom clients be expected to be able to perform XSLT translations? Or should transformations be left to an extension, or to external resources that do transformations? Individual applications that support XSLT could allow their users to specify stylesheets for transforming documents between particular formats (and could come with a few built in stylesheets). Note in Google how, when a PDF document comes up in a search, they give you a "View as HTML" link. The app could present a UI for following a link as it is, or converting it to a supported format. From my perspective, this doesn't seem like something that atom:link should be burdened with, and it may not even belong in the core at all. > Now say you want to say that a particular entry is associated with a > particular category in a remotely-defined scheme. > > scheme: http://www.flickr.com > category: http://www.flickr.com/photos/tags/kitten/ > > Again, how would you express that? > What do you think a typical client might display, and what behaviour > might be available? Leave that to a different element, al la RSS 2.0's "category" element: http://www.flickr.com/photos/tags/kitten/ > On Wed, 20 Oct 2004 07:58:34 -0600, Antone Roundy > wrote: >> >> On Wednesday, October 20, 2004, at 05:47 AM, Danny Ayers wrote: >>> If is refactored as has been discussed ( etc), and >>> there are other routes to extensibility under discussion, I don't >>> really have any major objection to what remains being >>> HTML--like. >>> >>> I'm still not sure it's entirely appropriate, as Atom is more >>> data-oriented (for want of a better divide) that HTML, so the >>> doc-oriented usage in Moz doesn't seem to mesh well. But what's left >>> of this issue is at its heart only about element naming, not a big >>> deal. >>> >> The Mozilla approach shows exactly what I'd like to see applications >> able to do with , the difference being that in the case of Atom, >> the spec should be where things like stylesheets are removed from the >> list. In other words, "stylesheet" et al should not be allowed into >> @rel. Allow me to repeat in this context what I've said on this >> subject before. >> >> In most cases, webmasters don't link to stylesheets so that people can >> see the stylesheet, but so that browsers will format the webpage based >> on it. When they DO want people to SEE the stylesheet, they link to >> it >> with , not with . In the same way, Atom publishers should >> only put things into that they want people to be able to >> traverse a link directly to. This could include another feed, perhaps >> an atom:entry (if we decide an entry can be a document element), a >> webpage, a particular anchor within a webpage, a PDF file, a JPEG >> image, etc. A JPEG image is another example of where it is the >> publisher's intention that governs whether to use or some >> other mechanism. In some cases, the publisher intends for an image to >> be displayed within a webpage. In those cases they use . In >> other cases, they intend it to be displayed by itsself. In those >> cases, they use . as with stylesheets, is for the >> case, not the case. >> >> Whatever spec text we come up with to define what an atom:link is, >> perhaps a PROSE example or two like the above discussion of >> stylesheets >> and images would be advantageous, just to be sure that people >> understand. I'll have to think on some language for PaceLinkPurpose >> based on the above... >> >> > > > -- > > http://dannyayers.com > From owner-atom-syntax@mail.imc.org Wed Oct 20 12:08:28 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 MAA18103 for ; Wed, 20 Oct 2004 12:08:28 -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 i9KG1niq059506; Wed, 20 Oct 2004 09:01:49 -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 i9KG1nsb059505; Wed, 20 Oct 2004 09:01:49 -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 i9KG1mKH059493 for ; Wed, 20 Oct 2004 09:01:48 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 54028 messnum 396634 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 20 Oct 2004 16:01:45 -0000 Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.25?) (62.77.172.85) by mail05.svc.cra.dublin.eircom.net (qp 54028) with SMTP; 20 Oct 2004 16:01:45 -0000 Message-ID: <41768BE3.4080102@dehora.net> Date: Wed, 20 Oct 2004 17:01:39 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= 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: Norman Walsh , Atom Syntax , Dare Obasanjo Subject: tag soup [was: Time to add advertising to Atom?] References: <20041018191706.54785.qmail@web41203.mail.yahoo.com> <877jplo9p9.fsf@nwalsh.com> In-Reply-To: <877jplo9p9.fsf@nwalsh.com> 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 Norman Walsh wrote: > / Dare Obasanjo was heard to say: > | > | Why would any client want to explicitly support a > | mechanism for shoving ads in users faces regardless of > | whether it is in an extension or a 'mandatory' part of > | Atom? > > Indeed. The sole value I can think of for standarization is that > clients would know what content to suppress with extreme prejudice. > > Maybe that's a really, really good reason to sandardize it :-) Since a standardized slot for advertising will ensure no ads are present there, we could use it to tunnel content through Atom feeds :) cheers Bill From owner-atom-syntax@mail.imc.org Wed Oct 20 12:26: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 MAA20601 for ; Wed, 20 Oct 2004 12:26: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 i9KGIGHs064245; Wed, 20 Oct 2004 09:18: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 i9KGIGZw064244; Wed, 20 Oct 2004 09:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40810.mail.yahoo.com (web40810.mail.yahoo.com [66.218.78.187]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9KGIGTA064235 for ; Wed, 20 Oct 2004 09:18:16 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041020161814.88248.qmail@web40810.mail.yahoo.com> Received: from [24.18.132.123] by web40810.mail.yahoo.com via HTTP; Wed, 20 Oct 2004 09:18:14 PDT Date: Wed, 20 Oct 2004 09:18:14 -0700 (PDT) From: Dare Obasanjo Subject: Re: IANA registry vs. URIs To: Danny Ayers , Antone Roundy Cc: atom-syntax@imc.org In-Reply-To: <1f2ed5cd0410200737ba6dfe8@mail.gmail.com> 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: --- Danny Ayers wrote: > > Quick practical questions on this approach. Let's > say the linked > information is an XSLT-transformed version of the > feed, say into > docbook format. > > feed is at http://example.org/feed.atom > stylesheet at http://example.org/atom2docbook.xsl > > How would you express that? > What do you think a typical client might display, > and what behaviour > might be available? I don't see why you'd want to express that with a element despite whatever inconsistent brokenness exists in HTML today. > Now say you want to say that a particular entry is > associated with a > particular category in a remotely-defined scheme. > > scheme: http://www.flickr.com > category: http://www.flickr.com/photos/tags/kitten/ > > Again, how would you express that? > What do you think a typical client might display, > and what behaviour > might be available? I agree with Antone and Robert, use some other element for this not . ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Wed Oct 20 12:57:24 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 MAA25231 for ; Wed, 20 Oct 2004 12:57:23 -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 i9KGn2fO072146; Wed, 20 Oct 2004 09:49: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 i9KGn2ik072145; Wed, 20 Oct 2004 09:49: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 i9KGn1jl072112 for ; Wed, 20 Oct 2004 09:49: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 <20041020164857016000m1kge>; Wed, 20 Oct 2004 16:48:57 +0000 Date: Wed, 20 Oct 2004 10:48:55 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceLinkPurpose - working on the wording From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: 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 I've added the following to PaceLinkPurpose, just below the mention of @rel values being defined by extensions: '''Note to extension authors:''' When deciding whether to use an Atom Link Construct in your extension, or whether to use or define a different element, consider the following examples of appropriate usage. Example 1: If an HTML author intends for a stylesheet to be used to apply styling to an HTML page, they reference it using the HTML tag. If they intend for the visitor to view the stylesheet itself, they reference it using the tag. Link Constructs are to be used only for the tag case. Example 2: To reference an image to be displayed within an HTML document, the tag is used. To point to an image to be displayed by itself, the tag is used. Again, Link Constructs are only to be used for the tag case. On another note, I would not object to removing the sentence "When retrieving the resource pointed to by the href attribute using HTTP, the GET method MUST be used." The remaining definition of a Link Construct would be: A Link Construct specifies a hyperlink primarily intended to be traversed in response to an explicit user action such as clicking, selecting a menu item, drag and drop, etc. It MUST NOT have any child content. We could go a little further and define it something like this: A Link Construct specifies a hyperlink to a resource related to its parent, which is primarily intended to be traversed in response to an explicit user action such as clicking, selecting a menu item, drag and drop, etc. A final thought: if people are concerned about the possibility of confusion with HTML's link tag, we could call Atom's element atom:hlink (hyperlink) or something. From owner-atom-syntax@mail.imc.org Wed Oct 20 13:20:56 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 NAA28670 for ; Wed, 20 Oct 2004 13:20:55 -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 i9KHCLjl078565; Wed, 20 Oct 2004 10:12: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 i9KHCLaE078564; Wed, 20 Oct 2004 10:12:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40811.mail.yahoo.com (web40811.mail.yahoo.com [66.218.78.188]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9KHCKi5078543 for ; Wed, 20 Oct 2004 10:12:20 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041020171219.18022.qmail@web40811.mail.yahoo.com> Received: from [131.107.71.94] by web40811.mail.yahoo.com via HTTP; Wed, 20 Oct 2004 10:12:19 PDT Date: Wed, 20 Oct 2004 10:12:19 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkPurpose - working on the wording To: Antone Roundy , atom-syntax@imc.org In-Reply-To: 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: --- Antone Roundy wrote: > > I've added the following to PaceLinkPurpose, ... > Example 1: If an HTML author intends for a > stylesheet to be used to > apply styling to > an HTML page, they reference it using the HTML > tag. If they > intend for the > visitor to view the stylesheet itself, they > reference it using the > tag. Link > Constructs are to be used only for the tag > case. This example is confusing since you use the example of how things work with the HTML element then say "Don't do that". > Example 2: To reference an image to be > displayed within an HTML > document, the > tag is used. To point to an image to be > displayed by itself, the > tag is used. > Again, Link Constructs are only to be used for > the tag case. Instead of using these examples why not just grab the definitions and exposition from the HTML 4.0 spec since it is clear that's the idea you are trying to get across? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Wed Oct 20 13:30: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 NAA29557 for ; Wed, 20 Oct 2004 13:29:59 -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 i9KHMNit081133; Wed, 20 Oct 2004 10:22: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 i9KHMNOC081132; Wed, 20 Oct 2004 10:22:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KHMMJd081106 for ; Wed, 20 Oct 2004 10:22:22 -0700 (PDT) (envelope-from sc@itst.net) Received: from [192.168.1.10] (p5081613F.dip0.t-ipconnect.de [80.129.97.63]) by cat-proof.de (Postfix) with ESMTP id B18C4340B674 for ; Wed, 20 Oct 2004 19:19:38 +0200 (CEST) Message-ID: <41769ECF.40509@itst.net> Date: Wed, 20 Oct 2004 19:22:23 +0200 From: Sascha Carlin User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: Time to add advertising to Atom? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: >> Is this a demand Atom should meet? How can we meet it? > With an extension. What's the reson to not put it in Atom core? Just curious, Sascha From owner-atom-syntax@mail.imc.org Wed Oct 20 13:43:49 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 NAA01350 for ; Wed, 20 Oct 2004 13:43:49 -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 i9KHbCEo085142; Wed, 20 Oct 2004 10:37: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 i9KHbCPN085141; Wed, 20 Oct 2004 10:37:12 -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 i9KHbCfX085130 for ; Wed, 20 Oct 2004 10:37:12 -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 <20041020173710016000iakme>; Wed, 20 Oct 2004 17:37:10 +0000 Date: Wed, 20 Oct 2004 11:37:09 -0600 Subject: Re: PaceLinkPurpose - working on the wording 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: <20041020171219.18022.qmail@web40811.mail.yahoo.com> Message-Id: 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, October 20, 2004, at 11:12 AM, Dare Obasanjo wrote: > --- Antone Roundy wrote: >> I've added the following to PaceLinkPurpose, > ... >> Example 1: If an HTML author intends for a >> stylesheet to be used to >> apply styling to >> an HTML page, they reference it using the HTML >> tag. If they >> intend for the >> visitor to view the stylesheet itself, they >> reference it using the >> tag. Link >> Constructs are to be used only for the tag >> case. > > This example is confusing since you use the example of > how things work with the HTML element then say > "Don't do that". > The point I'm trying to make is that Atom Link Constructs are NOT the same as HTML's link tag. I suppose I could start off the example with a sentence that says that explicitly. >> Example 2: To reference an image to be >> displayed within an HTML >> document, the >> tag is used. To point to an image to be >> displayed by itself, the >> tag is used. >> Again, Link Constructs are only to be used for >> the tag case. > > Instead of using these examples why not just grab the > definitions and exposition from the HTML 4.0 spec > since it is clear that's the idea you are trying to > get across? > Link Constructs are much closer to the HTML tag, but of course, not identical (they don't have @name, @accesskey, @shape, @coords, @tabindex, @onfocus, etc.) I took a look at the spec, but didn't see anything that seemed to me to define the concept I'm getting at more clearly. The point of the two examples is to tell people not to do two of the things that people have historically tried to add values to @atom:rel to do. I suspect that if we don't explicitly call these things out, people are going to pollute atom:link with extensions that make it unsuitable for use in a manner similar to what Mozilla does with links after it has filtered out a few values. From owner-atom-syntax@mail.imc.org Wed Oct 20 14:08: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 OAA04140 for ; Wed, 20 Oct 2004 14:08:19 -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 i9KI0HTM091443; Wed, 20 Oct 2004 11:00:17 -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 i9KI0H7M091441; Wed, 20 Oct 2004 11:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40810.mail.yahoo.com (web40810.mail.yahoo.com [66.218.78.187]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9KI0GOI091426 for ; Wed, 20 Oct 2004 11:00:16 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041020180015.98496.qmail@web40810.mail.yahoo.com> Received: from [131.107.76.143] by web40810.mail.yahoo.com via HTTP; Wed, 20 Oct 2004 11:00:15 PDT Date: Wed, 20 Oct 2004 11:00:15 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceLinkPurpose - working on the wording To: Antone Roundy , atom-syntax@imc.org In-Reply-To: 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: --- Antone Roundy wrote: > > > Link Constructs are much closer to the HTML tag, > but of course, not > identical (they don't have @name, @accesskey, > @shape, @coords, > @tabindex, @onfocus, etc.) I took a look at the > spec, but didn't see > anything that seemed to me to define the concept I'm > getting at more > clearly. The HTML spec has a clear definition of what it means to be an anchor, see http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 in case you missed it. Instead of trying to paraphrase what the experts in that area have written it makes more sense to me to either grab the text from there or simply reference the definitions in the HTML spec. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Wed Oct 20 14:25:27 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 OAA06669 for ; Wed, 20 Oct 2004 14:25:26 -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 i9KIHrDk095636; Wed, 20 Oct 2004 11:17: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 i9KIHrtp095635; Wed, 20 Oct 2004 11:17:53 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KIHljI095595; Wed, 20 Oct 2004 11:17:48 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <41769ECF.40509@itst.net> References: <41769ECF.40509@itst.net> Date: Wed, 20 Oct 2004 11:17:48 -0700 To: Sascha Carlin , Atom-Syntax From: Paul Hoffman / IMC Subject: Re: Time to add advertising to Atom? 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 7:22 PM +0200 10/20/04, Sascha Carlin wrote: >What's the reson to not put it in Atom core? It's not in our charter, and there is *lots* that is not in our charter that "might be useful". As long as we have a good extension mechanism, the core should be just that: a core. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Oct 20 14:52: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 OAA09978 for ; Wed, 20 Oct 2004 14:52: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 i9KIjRLF002542; Wed, 20 Oct 2004 11:45:27 -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 i9KIjRtA002541; Wed, 20 Oct 2004 11:45:27 -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 i9KIjRBB002524 for ; Wed, 20 Oct 2004 11:45:27 -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 <20041020184525016000ngppe>; Wed, 20 Oct 2004 18:45:26 +0000 Date: Wed, 20 Oct 2004 12:45:24 -0600 Subject: Re: PaceLinkPurpose - working on the wording 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: <20041020180015.98496.qmail@web40810.mail.yahoo.com> Message-Id: <33B6B436-22C8-11D9-9F3F-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, October 20, 2004, at 12:00 PM, Dare Obasanjo wrote: > --- Antone Roundy wrote: >>> Link Constructs are much closer to the HTML > tag, >> but of course, not >> identical (they don't have @name, @accesskey, >> @shape, @coords, >> @tabindex, @onfocus, etc.) I took a look at the >> spec, but didn't see >> anything that seemed to me to define the concept I'm >> getting at more >> clearly. > > The HTML spec has a clear definition of what it means > to be an anchor, see > http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 > in case you missed it. I looked there. > Instead of trying to paraphrase > what the experts in that area have written it makes > more sense to me to either grab the text from there or > simply reference the definitions in the HTML spec. I don't think referencing the HTML spec would do, given that there are differences between atom:link/Atom's Link Construct and HTML's and elements. In retrospect at least, we can see that the experts created kind of a sloppy element in --the special casing that Mozilla does with it being the perfect example of the flaw. is much better--it's usage is consistent--but it's not exactly what we're aiming for. Some of the differences are pointed out above (the quote from my previous email). Restating part of that conceptually, Atom's Link Constructs are not going to be used as the destination endpoints of a link the way an element with @name is. If we adopt the @rev attribute, they will in a way become destination endpoints, but still not quite in the way with @name is--at least not in any usage I've ever seen. As for clear definitions, I think they have good general definitions, but nothing specific enough for Link Constructs. Here are a few candidates and what they're missing. "A link is a connection from one Web resource to another." Yes, but we need to be more specific. For example, we DON'T mean the kind of connection created by img/@src, which fits that sentence fine. 'A link has two ends -- called anchors -- and a direction. The link starts at the "source" anchor and points to the "destination" anchor, which may be any Web resource (e.g., an image, a video clip, a sound bite, a program, an HTML document, an element within an HTML document, etc.)' Sure, and we may want to add some prose like that, but it doesn't get at the details of what one specific type of link which we call the Link Construct does. This is a fairly general statement that by itself covers a lot more ground than the Link Construct. "The default behavior associated with a link is the retrieval of another Web resource. This behavior is commonly and implicitly obtained by selecting the link (e.g., by clicking, through keyboard input, etc.)." Sure, and we may want some prose like this, but this is talking about behavior. We don't yet have a definition of a Link Construct. If there's "a clear definition of what it means to be an anchor" that would accurately define what it means to be a Link Construct, I don't see it there. If you see something there that would work, please point out the specific text rather than just pointing to a document and expecting someone else to do it. From owner-atom-syntax@mail.imc.org Wed Oct 20 15:22:59 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 PAA15109 for ; Wed, 20 Oct 2004 15:22:59 -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 i9KJDvYR008574; Wed, 20 Oct 2004 12:13: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 i9KJDvLl008573; Wed, 20 Oct 2004 12:13:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9KJDuff008533 for ; Wed, 20 Oct 2004 12:13:56 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by nappa.corp.google.com (8.12.11/8.12.11) with ESMTP id i9KJDqNI029504 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 20 Oct 2004 12:13:52 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2DC2B9B3-22CC-11D9-BE4D-000A95B09B46@google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom syntax list From: steve jenson Subject: XML2004Hackathon Date: Wed, 20 Oct 2004 12:13:52 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sofar, only 5 people have signed up for the Interop Hackathon at XML2004[*]. I want to book my reservations but is this going to be cancelled as the last IETF Meeting did? If so, let's put together an IRC channel and a time/date to have this interop hackathon. Thanks, Steve [*]http://www.intertwingly.net/wiki/pie/XML2004Hackathon From owner-atom-syntax@mail.imc.org Thu Oct 21 07:20:58 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 HAA01295 for ; Thu, 21 Oct 2004 07:20:57 -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 i9LBAN7V046360; Thu, 21 Oct 2004 04:10: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 i9LBANjT046359; Thu, 21 Oct 2004 04:10:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LBAJUr046026 for ; Thu, 21 Oct 2004 04:10:22 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 21 Oct 2004 21:09:57 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Oct 2004 21:09:49 +1000 Subject: namespaced linking extensibility - some problems in practice From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9LBANUr046338 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit paraphrasing... it's been proposed to use external modules for linking extensibility, which would look something like this: with either the URI of the names space declaration being representative of the relationship involved, or the namespace+elementname being so. This wasn't really clear in the discussions to date, being handwaved more or less. (if someone did explain this, please forgive me - I plead too many emails) Resigned to the thought that this might be the way we will go, I've been playing with some examples in an attempt to understand it better. Most if not all examples on the list so far have been expressed in generic form, and not attempts at using a known external module or known relationship type (eg. dublin core). So ... Dublin Core has a relationship type of 'isReplacedBy', one which an atom agent might find interesting enough to do stuff with (other than simply render it as a human-clickable link) ... Turns out xlink has an 'arcrole' attribute, which is analogous to @rel. Thus, a 'DC.isReplacedBy' link might be expressed as Meanwhile, some other publisher might want to express a link using the same relationship, but instead uses this form: Then a third publisher decides to express the same thing this way: URI-to-resource And a fourth publisher does this (and why not?): title-of-resource Now we have four ways of expressing a link with a well defined relationship, but no easy way of detecting they are the same without first recognising all four forms. Undoubtedly there might be yet more ways of expressing the same thing ... topic maps can be expressed in XML, for example. There is no defence against perversity, we know that. However if one publisher wants to re-use their investment in using DC XML, while another drinks the xlink koolaid ... that's not perversity. That¹s a problem. e. From owner-atom-syntax@mail.imc.org Thu Oct 21 09:08: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 JAA24858 for ; Thu, 21 Oct 2004 09:08: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 i9LCwWj1076089; Thu, 21 Oct 2004 05:58: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 i9LCwWZI076088; Thu, 21 Oct 2004 05:58:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LCwVd6076072 for ; Thu, 21 Oct 2004 05:58:31 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id 75so25919rnl for ; Thu, 21 Oct 2004 05:58:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=U4pQG4fHS1dy/oP4c2RX0lhYzsO3gLs3+27nZhmAnfVlI6xzLzafmiE5bMKfNsr6DhmLjfn3HpM9KO/DMLSKIPB8hkEU3+S+wlQcsiDEgf9lK7bqhs5HoIst5tRf74OLc+dGPMgBU/94kbhCDx2lT4GvpLfJuLTJUfmrldUbxgs= Received: by 10.38.181.77 with SMTP id d77mr3063842rnf; Thu, 21 Oct 2004 05:58:30 -0700 (PDT) Received: by 10.38.151.74 with HTTP; Thu, 21 Oct 2004 05:58:30 -0700 (PDT) Message-ID: <3f1451f5041021055860ba504f@mail.gmail.com> Date: Thu, 21 Oct 2004 08:58:30 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Eric Scheid Subject: Re: namespaced linking extensibility - some problems in practice Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9LCwVd6076075 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I've followed this road before: http://bitworking.org/news/Not_Invented_Here In that article I link to two example feeds, one using the current syntax[1] and the other re-using as many other XML vocabularies as possible[2]: [1] http://bitworking.org/projects/atom/examples/original.atom.html [2] http://bitworking.org/projects/atom/examples/reuse.atom.html -joe On Thu, 21 Oct 2004 21:09:49 +1000, Eric Scheid wrote: > > paraphrasing... it's been proposed to use external modules for linking > extensibility, which would look something like this: > > xmlns:ns1="http://example.org/foo" > atom:href="..." .../> > > with either the URI of the names space declaration being representative of > the relationship involved, or the namespace+elementname being so. This > wasn't really clear in the discussions to date, being handwaved more or > less. (if someone did explain this, please forgive me - I plead too many > emails) > > Resigned to the thought that this might be the way we will go, I've been > playing with some examples in an attempt to understand it better. Most if > not all examples on the list so far have been expressed in generic form, and > not attempts at using a known external module or known relationship type > (eg. dublin core). > > So ... Dublin Core has a relationship type of 'isReplacedBy', one which an > atom agent might find interesting enough to do stuff with (other than simply > render it as a human-clickable link) ... > > Turns out xlink has an 'arcrole' attribute, which is analogous to @rel. > > Thus, a 'DC.isReplacedBy' link might be expressed as > > xlink:type="simple" > xlink:arcrole="http://purl.org/DC/1.0/terms/isReplacedBy" > xlink:href="URI-to-resource" > atom:href="URI-to-resource" > /> > > Meanwhile, some other publisher might want to express a link using the same > relationship, but instead uses this form: > > xhtml:rel="DC.isReplacedBy" > xhtml:href="URI-to-resource" > atom:href="URI-to-resource" > /> > > Then a third publisher decides to express the same thing this way: > > atom:href="URI-to-resource">URI-to-resource > > And a fourth publisher does this (and why not?): > > html:rel="DC.isReplacedBy" > html:href="URI-to-resource" > atom:href="URI-to-resource">title-of-resource > > Now we have four ways of expressing a link with a well defined relationship, > but no easy way of detecting they are the same without first recognising all > four forms. Undoubtedly there might be yet more ways of expressing the same > thing ... topic maps can be expressed in XML, for example. > > There is no defence against perversity, we know that. However if one > publisher wants to re-use their investment in using DC XML, while another > drinks the xlink koolaid ... that's not perversity. > > That¹s a problem. > > e. > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Oct 21 10:03:36 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 KAA00832 for ; Thu, 21 Oct 2004 10:03: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 i9LDsYZv089657; Thu, 21 Oct 2004 06:54: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 i9LDsYM2089656; Thu, 21 Oct 2004 06:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40806.mail.yahoo.com (web40806.mail.yahoo.com [66.218.78.183]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LDsX3r089618 for ; Thu, 21 Oct 2004 06:54:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041021135431.38629.qmail@web40806.mail.yahoo.com> Received: from [24.18.132.123] by web40806.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 06:54:31 PDT Date: Thu, 21 Oct 2004 06:54:31 -0700 (PDT) From: Dare Obasanjo Subject: namespaced extensibility - some problems in practice To: Eric Scheid , Atom Syntax In-Reply-To: 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: Changing the title since this isn't about linking specifically. What you are pointing out is that if people are allowed to use namespaced extensions, it is likely that they might use different extensions for expressing the same concept. We have this in RSS today with the various content modules ( content:encoded & xhtml:body, dc:author & dc:creator, etc). This applies to all protocols and markup formats that allow extensibility in a decentralized manner. The only way to prevent this is to disallow decentralized extensibility. --- Eric Scheid wrote: > > paraphrasing... it's been proposed to use external > modules for linking > extensibility, which would look something like this: > > xmlns:ns1="http://example.org/foo" > atom:href="..." .../> > > with either the URI of the names space declaration > being representative of > the relationship involved, or the > namespace+elementname being so. This > wasn't really clear in the discussions to date, > being handwaved more or > less. (if someone did explain this, please forgive > me - I plead too many > emails) > > Resigned to the thought that this might be the way > we will go, I've been > playing with some examples in an attempt to > understand it better. Most if > not all examples on the list so far have been > expressed in generic form, and > not attempts at using a known external module or > known relationship type > (eg. dublin core). > > So ... Dublin Core has a relationship type of > 'isReplacedBy', one which an > atom agent might find interesting enough to do stuff > with (other than simply > render it as a human-clickable link) ... > > Turns out xlink has an 'arcrole' attribute, which is > analogous to @rel. > > Thus, a 'DC.isReplacedBy' link might be expressed as > > xmlns:xlink="http://www.w3.org/TR/1999/xlink" > xlink:type="simple" > > xlink:arcrole="http://purl.org/DC/1.0/terms/isReplacedBy" > xlink:href="URI-to-resource" > atom:href="URI-to-resource" > /> > > Meanwhile, some other publisher might want to > express a link using the same > relationship, but instead uses this form: > > xmlns:xhtml="http://www.w3.org/1999/xhtml" > xhtml:rel="DC.isReplacedBy" > xhtml:href="URI-to-resource" > atom:href="URI-to-resource" > /> > > Then a third publisher decides to express the same > thing this way: > > xmlns:dcterms="http://purl.org/DC/1.0/terms/" > > atom:href="URI-to-resource">URI-to-resource > > And a fourth publisher does this (and why not?): > > xmlns:html="http://www.w3.org/TR/REC-html40" > html:rel="DC.isReplacedBy" > html:href="URI-to-resource" > > atom:href="URI-to-resource">title-of-resource > > Now we have four ways of expressing a link with a > well defined relationship, > but no easy way of detecting they are the same > without first recognising all > four forms. Undoubtedly there might be yet more ways > of expressing the same > thing ... topic maps can be expressed in XML, for > example. > > There is no defence against perversity, we know > that. However if one > publisher wants to re-use their investment in using > DC XML, while another > drinks the xlink koolaid ... that's not perversity. > > That¹s a problem. > > e. > > > ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 21 10:29: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 KAA05874 for ; Thu, 21 Oct 2004 10:29:45 -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 i9LEL43k096480; Thu, 21 Oct 2004 07:21:04 -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 i9LEL4Me096479; Thu, 21 Oct 2004 07:21:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LEL3Gh096472 for ; Thu, 21 Oct 2004 07:21:04 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 21-Oct-2004 15:05:17 +0100 From: "Mark Birbeck" To: Subject: [ANN] Atom client implemented with XForms Date: Thu, 21 Oct 2004 15:05:07 +0100 Message-ID: <003f01c4b776$fb6b1760$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello everyone, Just a quick note to say that if anyone is interested, we've implemented an Atom client using XForms. My main motivation for doing it was to see what features would need to be added to XForms in order to make it work with 'layered' protocols such as Atom and WebDAV. There are quite a few features that we need that are not in XForms 1.0, but by adding them to formsPlayer (my company's product) to get the Atom client to work, I believe we've provided a strong argument for their inclusion in the forthcoming XForms 1.1. However, I'm no expert on Atom, so I'd recommend that if you see other features that you think should be added to the XForms language that would make a difference in your space, you should suggest them on the XForms Working Group mailing list: An XForm that interacts with Blogger.com (not currently a great implementation of the Atom API!) is available from our home page: All the best, and keep up the good work! Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Thu Oct 21 10:54: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 KAA09643 for ; Thu, 21 Oct 2004 10:54: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 i9LEiHJN004073; Thu, 21 Oct 2004 07:44:17 -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 i9LEiHWX004072; Thu, 21 Oct 2004 07:44:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LEiGIC003809 for ; Thu, 21 Oct 2004 07:44:16 -0700 (PDT) (envelope-from johan@opera.com) Received: from capitole.oslo.opera.com (pc096.lan024.oslo.opera.com [10.20.24.96] (may be forged)) (authenticated bits=0) by sam.opera.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i9LEhxSd019883; Thu, 21 Oct 2004 14:43:59 GMT Date: Thu, 21 Oct 2004 16:43:58 +0200 To: bob@wyman.us, "'atom-syntax.imc.org'" Subject: Re: Article importance References: <200410192123.BVL72637@ms8.netsolmail.com> From: "Johan H. Borg" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200410192123.BVL72637@ms8.netsolmail.com> User-Agent: Opera M2/7.60 (Win32, build 7252) X-Scanned-By: MIMEDefang 2.39 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi again, Thanks for great feedback everyone! I agree that this is likely a candidate for an extension. On Tue, 19 Oct 2004 17:23:23 -0400, Bob Wyman wrote: > If you have a fixed scale of importance (perhaps 1 to 10), then what > do you do when you publish a new entry whose "importance" is greater than > all previously published entries yet you've already used the highest > measure > for something in the past? Can the scale of importance be anything other > than open ended? Importance may tend to decay over time. Would you define > such a decay function? The end-user client could define such a function any way it wants to and it even depends on the use case. Sometimes you just want to know which are the most important entries received the last hour so you can display the breaking news from several sources combined. In this case importance falls to Normal after an hour, for other uses you may choose a different decay function. > Sometimes, the importance of an old entry might be > considered to increase after it is published. If this happens, would you > have people republish items to adjust their importance metrics? They do today, sometimes just to fix a typo (you see this a lot in feeds from online newspapers..). On the other hand, if the importance of an event increases, it would typically be because of new information, so a new entry makes sense. Thanks, Johan. From owner-atom-syntax@mail.imc.org Thu Oct 21 12:15:26 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 MAA18386 for ; Thu, 21 Oct 2004 12:15:26 -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 i9LG5iId025147; Thu, 21 Oct 2004 09:05: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 i9LG5ig1025146; Thu, 21 Oct 2004 09:05:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LG5h0n025140 for ; Thu, 21 Oct 2004 09:05:43 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so17952rnb for ; Thu, 21 Oct 2004 09:05:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=fvYTPlj5KHQvTpLHKY2RCG02R6w0J/n+1Uco/uHZQEJHUfkAQfhQ92NfnbwW4VHnD+xltv2urO/MFllryN62j9dRBnw+EzC66ynemGTBJmMSTBO/8zm3hR6Q1O0I4nTasyj9Ykzzj7L9oeTgh1VvAE8Lh/o0CamMpK3RaWtLDgE= Received: by 10.38.8.2 with SMTP id 2mr204570rnh; Thu, 21 Oct 2004 09:05:46 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 21 Oct 2004 09:05:46 -0700 (PDT) Message-ID: <1f2ed5cd041021090564943bd8@mail.gmail.com> Date: Thu, 21 Oct 2004 18:05:46 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: namespaced extensibility - some problems in practice Cc: Eric Scheid , Atom Syntax In-Reply-To: <20041021135431.38629.qmail@web40806.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041021135431.38629.qmail@web40806.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 06:54:31 -0700 (PDT), Dare Obasanjo wrote: > > Changing the title since this isn't about linking > specifically. > > What you are pointing out is that if people are > allowed to use namespaced extensions, it is likely > that they might use different extensions for > expressing the same concept. We have this in RSS today > with the various content modules ( content:encoded & > xhtml:body, dc:author & dc:creator, etc). This applies > to all protocols and markup formats that allow > extensibility in a decentralized manner. > > The only way to prevent this is to disallow > decentralized extensibility. True, and I'm sure you'd agree there is some cost associated with such duplication. But that doesn't make decentralized extensibility any less desirable, and there are ways of minimising the potential for duplication and offsetting the cost should it occur. Duplication can be minimised by constraining the extensibility in such a way that there are fewer ways of saying the same thing. XML does this at the syntax level with its definition of well-formedness and differentiation between things like elements and PIs. It's also possible to define a higher-level language in which the extensions can be expressed - this doesn't actually have to be a particularly sophisticated language, merely an association between certain syntax patterns and their interpretations within a logical data model and/or a processing model. XSLT's extensibility is a good example. The cost of duplication can be reduced by having a way of expressing that different constructs are equivalent. There's another simple example with XSLT - you can state that data expressed in format X on applying the transformation becomes the same as data expressed in format Y. This again is operating at the syntax level, but useful statements of equivalence can be made at the semantic level by using languages like OWL, e.g. rss:item owl:sameClassAs atom:entry. I think it's worth noting that minimisation of duplication as described here and a facility for expressing equivalence are available in RSS 1.0, both through its extension mechanism. Cheers, Danny. PS. dc:author?? -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 21 12:18:04 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 MAA18969 for ; Thu, 21 Oct 2004 12:18: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 i9LGA96n026151; Thu, 21 Oct 2004 09:10:09 -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 i9LGA9bu026150; Thu, 21 Oct 2004 09:10:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LGA8WU026113 for ; Thu, 21 Oct 2004 09:10:09 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 97CB0A4F32E; Thu, 21 Oct 2004 12:10:05 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Johan H. Borg'" , , "'atom-syntax.imc.org'" Subject: RE: Article importance Date: Thu, 21 Oct 2004 12:10:09 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS3fHwnSr/bWua+SVOxORx2j99l4wACkAOw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Message-Id: <20041021161005.97CB0A4F32E@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Johan H. Borg wrote: > The end-user client could define such a[n importance decay] > function any way it wants to and it even depends on the use case. What the client does won't impact the protocol or the data provided by a publisher. What I'm concerned about is any proposal that would have publishers regularly modify importance-metrics that might be part of an Atom entry. If this was done, then most clients would probably decide that the entry was "modified" and would display it as a new entry. The result would be a user perception of an increase in duplicate entries (distinguished only by importance-metrics) as well as the counter-intuitive result that if you *lowered* the importance-metric for an item, it would tend to be treated by many clients as "important" because it was recently modified. In the worst case, one might implement an importance-metric that caused the importance-metrics of all items to be modified whenever any new item was modified. Even worse would be something like a publisher-side system that caused entries to be regularly republished with modified time-dependent importance-metrics on some sort of schedule. The result could be that *all* entries in a feed appear to be "modified" every time that feed is fetched. The effect would be something like that which results from the "spam-blogs" that currently update the dates of all their entries every time the feed is fetched. This would not be good. My personal feeling is that if an importance-metric is provided, it should only rank the current entry in terms of previously published entries -- not entries published in the future. Thus, importance should be a metric of "importance at the time of publishing." It should not change over time unless a modification to some other element in the entry is changed and the entry republished for some purpose other than modifying its importance. In any case, I think you will find it very difficult to produce "cross-feed" importance measures that are meaningful. Thus, importance-metrics are likely to be ignored by aggregate feed generators. They should be considered, at best, blog-local metrics. bob wyman From owner-atom-syntax@mail.imc.org Thu Oct 21 12:57:48 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 MAA22891 for ; Thu, 21 Oct 2004 12:57:48 -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 i9LGnoXc035728; Thu, 21 Oct 2004 09:49: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 i9LGnoJx035727; Thu, 21 Oct 2004 09:49:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40825.mail.yahoo.com (web40825.mail.yahoo.com [66.218.92.72]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LGnof2035705 for ; Thu, 21 Oct 2004 09:49:50 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041021164948.21239.qmail@web40825.mail.yahoo.com> Received: from [24.18.132.123] by web40825.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 09:49:48 PDT Date: Thu, 21 Oct 2004 09:49:48 -0700 (PDT) From: Dare Obasanjo Subject: Re: namespaced extensibility - some problems in practice To: Danny Ayers Cc: Eric Scheid , Atom Syntax In-Reply-To: <1f2ed5cd041021090564943bd8@mail.gmail.com> 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: --- Danny Ayers wrote: > > > The cost of duplication can be reduced by having a > way of expressing > that different constructs are equivalent. There's > another simple > example with XSLT - you can state that data > expressed in format X on > applying the transformation becomes the same as data > expressed in > format Y. This again is operating at the syntax > level, but useful > statements of equivalence can be made at the > semantic level by using > languages like OWL, e.g. > rss:item owl:sameClassAs atom:entry. Yes and no. It allows clients to "learn" how to process different extensions but it doesn't change the fact that producers would be using different extensions with the same semantics. Technologies like OWL and XSLT are used after the fact to rationalize the semantically identical but syntactically different extensions in the wild. > I think it's worth noting that minimisation of > duplication as > described here and a facility for expressing > equivalence are available > in RSS 1.0, both through its extension mechanism. This does not jibe with my experiences in practice. Can you point out how RSS 1.0 prevents duplicative extensions in an environment that allows decentralized extensions? Before responding, reread my comments about OWL above. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 21 12:58: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 MAA22968 for ; Thu, 21 Oct 2004 12:57:59 -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 i9LGprFt036409; Thu, 21 Oct 2004 09:51: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 i9LGprSf036403; Thu, 21 Oct 2004 09:51:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40829.mail.yahoo.com (web40829.mail.yahoo.com [66.218.92.76]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9LGprFk036382 for ; Thu, 21 Oct 2004 09:51:53 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041021165151.18567.qmail@web40829.mail.yahoo.com> Received: from [24.18.132.123] by web40829.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 09:51:51 PDT Date: Thu, 21 Oct 2004 09:51:51 -0700 (PDT) From: Dare Obasanjo Subject: Re: namespaced extensibility - some problems in practice To: Danny Ayers Cc: Eric Scheid , Atom Syntax In-Reply-To: <1f2ed5cd041021090564943bd8@mail.gmail.com> 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: --- Danny Ayers wrote: > > PS. dc:author?? http://www.google.com/search?q=dc%3Aauthor+RSS ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 21 13:59: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 NAA29498 for ; Thu, 21 Oct 2004 13:59: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 i9LHpE4a051364; Thu, 21 Oct 2004 10:51:14 -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 i9LHpDnl051363; Thu, 21 Oct 2004 10:51:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHpD1l051340 for ; Thu, 21 Oct 2004 10:51:13 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so25348rnb for ; Thu, 21 Oct 2004 10:51:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=e0tvEkPMtqGfOrQpVbRhnG/GcUGouquJFBBMfa53rduCxAdztEH8hRY3MDNlVW711XsK9i9zo6w81oDGiczMK8fb5B/esPRyJ65O/yp3uJGCK8f2h/5K1/svQCvVyK2SPWASMyyNxdduSQdQB6O6jSHJ8p4GmQ98fDYZTH9Fb/A= Received: by 10.38.8.2 with SMTP id 2mr252578rnh; Thu, 21 Oct 2004 10:51:13 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 21 Oct 2004 10:51:13 -0700 (PDT) Message-ID: <1f2ed5cd041021105117b4597b@mail.gmail.com> Date: Thu, 21 Oct 2004 19:51:13 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: namespaced extensibility - some problems in practice Cc: Eric Scheid , Atom Syntax In-Reply-To: <20041021164948.21239.qmail@web40825.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 09:49:48 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > > > > > The cost of duplication can be reduced by having a > > way of expressing > > that different constructs are equivalent. There's > > another simple > > example with XSLT - you can state that data > > expressed in format X on > > applying the transformation becomes the same as data > > expressed in > > format Y. This again is operating at the syntax > > level, but useful > > statements of equivalence can be made at the > > semantic level by using > > languages like OWL, e.g. > > rss:item owl:sameClassAs atom:entry. > > Yes and no. It allows clients to "learn" how to > process different extensions but it doesn't change the > fact that producers would be using different > extensions with the same semantics. Ok (though I'd hesitate to use the word "learn" for something so mechanical). > Technologies like OWL and XSLT are used after the fact > to rationalize the semantically identical but > syntactically different extensions in the wild. Yep, ok. But I'd suggest this is generally a good thing on the Web, because it allows independent, decentralized development to take place while maintaining a consistent global whole. > > I think it's worth noting that minimisation of > > duplication as > > described here and a facility for expressing > > equivalence are available > > in RSS 1.0, both through its extension mechanism. > > This does not jibe with my experiences in practice. > Can you point out how RSS 1.0 prevents duplicative > extensions in an environment that allows decentralized > extensions? Before responding, reread my comments > about OWL above. I didn't say it prevents duplication, just that it minimises it. But ok, perhaps even that was too strong, maybe it would have been better to say it minimises the possible variation, making duplication easier to manage. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 21 14:01:43 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 OAA29735 for ; Thu, 21 Oct 2004 14:01:42 -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 i9LHtain052417; Thu, 21 Oct 2004 10:55:36 -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 i9LHtabc052416; Thu, 21 Oct 2004 10:55:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LHtZwK052407 for ; Thu, 21 Oct 2004 10:55:36 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so25664rnb for ; Thu, 21 Oct 2004 10:55:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=sSyg9WGSHsZGGSEMKAi0I8G6mxw2NhxFKU5CPGY7lRRplv6ydZbegnx5J9oOgFYIi3jazfUN7UJeSd4Hn1k7jCfQO2O88hUUb8lFiY1FoyU1q393WaxSHDa8UwlhZxHSgFWhtoeEgClUXgDOgOrabGRtc7AbG3JUV0tyoR0uPsY= Received: by 10.38.8.2 with SMTP id 2mr254937rnh; Thu, 21 Oct 2004 10:55:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 21 Oct 2004 10:55:38 -0700 (PDT) Message-ID: <1f2ed5cd041021105549535df4@mail.gmail.com> Date: Thu, 21 Oct 2004 19:55:38 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: namespaced extensibility - some problems in practice Cc: Eric Scheid , Atom Syntax In-Reply-To: <20041021165151.18567.qmail@web40829.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021165151.18567.qmail@web40829.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 09:51:51 -0700 (PDT), Dare Obasanjo wrote: > > --- Danny Ayers wrote: > > > > PS. dc:author?? > > http://www.google.com/search?q=dc%3Aauthor+RSS Hmm, namespace squatting is a different issue really, I don't think there's much we can do about that. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 21 15:40:56 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 PAA11695 for ; Thu, 21 Oct 2004 15:40:55 -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 i9LJWJxW076439; Thu, 21 Oct 2004 12:32: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 i9LJWJdG076438; Thu, 21 Oct 2004 12:32:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LJWIPY076429 for ; Thu, 21 Oct 2004 12:32:19 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10763; Thu, 21 Oct 2004 15:32:18 -0400 (EDT) Message-Id: <200410211932.PAA10763@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-format-03.txt Date: Thu, 21 Oct 2004 15:32:18 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename : draft-ietf-atompub-format-03.txt Pages : 32 Date : 2004-10-21 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-format-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-format-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-21154010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-format-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-format-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154010.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Thu Oct 21 15:53: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 PAA13465 for ; Thu, 21 Oct 2004 15:53:45 -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 i9LJlKqt080173; Thu, 21 Oct 2004 12:47: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 i9LJlKJe080172; Thu, 21 Oct 2004 12:47:20 -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 i9LJlJV3080142 for ; Thu, 21 Oct 2004 12:47:19 -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 1CKiu2-0007zC-GU for atom-syntax@imc.org; Thu, 21 Oct 2004 19:47:14 +0000 Message-ID: <41781245.30207@franklinmint.fm> Date: Thu, 21 Oct 2004 15:47:17 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: format-03 HTML and diffs 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 See what's new: http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.txt http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html http://atompub.org/2004/10/20/draft-ietf-atompub-format-03-from-2.diff.html Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 21 16:42: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 QAA22439 for ; Thu, 21 Oct 2004 16:42: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 i9LKWcic090788; Thu, 21 Oct 2004 13:32:38 -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 i9LKWcei090787; Thu, 21 Oct 2004 13:32:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LKWbqo090780 for ; Thu, 21 Oct 2004 13:32:37 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id 75so144848rnl for ; Thu, 21 Oct 2004 13:32:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=a9F5sSo0tm8Lb4L0z4hvK3u2d00RC8JrEzPfuNXSw/UZIK8+K/ZmrwQXjKva63VKkTpgUNd1eWcX+MvIYbei+xUvjR6lfKuf836FPeFOtF/yqbY6UJtO/DdywRRRpOOGzEpTgKYaJxFzY7fiFCLr5Do05ra1enebYiQgg9Gvwks= Received: by 10.38.181.77 with SMTP id d77mr3290297rnf; Thu, 21 Oct 2004 13:32:41 -0700 (PDT) Received: by 10.38.151.74 with HTTP; Thu, 21 Oct 2004 13:32:41 -0700 (PDT) Message-ID: <3f1451f504102113326265c37a@mail.gmail.com> Date: Thu, 21 Oct 2004 16:32:41 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Atom Syntax Subject: RFC2396bis now a Full Standard In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Given that RFC2396bis is now a full standard should we update the format and publication protocol specs to follow? -joe ---------- Forwarded message ---------- From: The IESG Date: Mon, 18 Oct 2004 18:07:22 -0400 Subject: Protocol Action: 'Uniform Resource Identifier (URI): Generic Syntax' to Full Standard To: IETF-Announce Cc: Internet Architecture Board , RFC Editor The IESG has approved the following document: - 'Uniform Resource Identifier (URI): Generic Syntax ' as a Full Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. Technical Summary This document advances the URI specification to Full Standard. It defines the generic syntax for URIs and describes a process for resolving URI references that are in relative form. It also contains guidelines for the use of URIs on the Internet and security considerations which are common to the use of URIs. The grammar it defines is a superset of valid URIs, so that a common parser or similar component can be built without scheme-specific data. Working Group Summary The URI working group is not active at this time, but the mailing list (uri@w3.org) remains active. Members of the mailing list reviewed this document extensively, and a comprehensive issues list was maintained, with recorded resolutions of each of the issues raised. The document also received editorial comments during Last Call; a new version of the document with additional explanatory text was generated in response to the issues raised. URIs are widely in used many Internet context, and there has been no dissent that a Full Standard updating RFC 2396 would be valuable. Protocol Quality This document was reviewed for the IESG by Ted Hardie. RFC Editor Note: OLD: URI comparison is performed in respect to some particular purpose, and implementations with differing purposes will often be subject to differing design trade-offs in regards to how much effort should be spent in reducing aliased identifiers. NEW: URI comparison is performed in respect to some particular purpose, and protocols or implementations comparing for purposes will often be subject to differing design trade-offs in regards to how much effort should be spent in reducing aliased identifiers. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Oct 21 17:48: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 RAA06600 for ; Thu, 21 Oct 2004 17:48: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 i9LLdtQF007693; Thu, 21 Oct 2004 14:39: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 i9LLdtIa007692; Thu, 21 Oct 2004 14:39: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 i9LLdsaV007648 for ; Thu, 21 Oct 2004 14:39:55 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 54C5E7C2E8; Thu, 21 Oct 2004 23:37:19 +0200 (CEST) To: "Joe Gregorio" , "Atom Syntax" Subject: Re: RFC2396bis now a Full Standard References: <3f1451f504102113326265c37a@mail.gmail.com> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 21 Oct 2004 23:40:12 +0200 In-Reply-To: <3f1451f504102113326265c37a@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 21 Oct 2004 16:32:41 -0400, Joe Gregorio wrote: > Given that RFC2396bis is now a full standard should we update the > format and publication protocol specs to follow? I think that's a good idea, yes. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Oct 21 17:58: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 RAA08167 for ; Thu, 21 Oct 2004 17:58: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 i9LLgASm008282; Thu, 21 Oct 2004 14:42:10 -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 i9LLgAxx008281; Thu, 21 Oct 2004 14:42:10 -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 i9LLg9CX008240 for ; Thu, 21 Oct 2004 14:42:10 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 2EF3C7C2E8; Thu, 21 Oct 2004 23:39:43 +0200 (CEST) To: "Laurent Le Meur" , atom-syntax@imc.org Subject: Re: Use of the NewsML URN by other initiatives References: <000601c4b047$0d1a4ad0$67b4329e@afp.local> Message-ID: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Thu, 21 Oct 2004 23:42:36 +0200 In-Reply-To: <000601c4b047$0d1a4ad0$67b4329e@afp.local> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 12 Oct 2004 12:34:25 +0200, Laurent Le Meur wrote: > Good news. > > [...] We would like other initiatives (e.g. the Atom community) to be > able to use the NewsML URN in their projects, and so we'd like to relax > the scope of the RFC (today closely associated with NewsML NewsItems). This is good news indeed. Thanks for sharing them with the list! -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Oct 21 19:51:33 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 TAA04167 for ; Thu, 21 Oct 2004 19:51:32 -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 i9LNhraA035430; Thu, 21 Oct 2004 16:43: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 i9LNhrhA035429; Thu, 21 Oct 2004 16:43:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9LNhovN035307 for ; Thu, 21 Oct 2004 16:43:53 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 22 Oct 2004 09:43:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 22 Oct 2004 09:43:17 +1000 Subject: Re: I-D ACTION:draft-ietf-atompub-format-03.txt From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200410211932.PAA10763@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > vemmi://example.org/2003/32397 the vemmi URI scheme is described here: http://www.rfc-archive.org/getrfc.php?rfc=2122 an odd choice for an URI (albeit it is actually supported with an RFC, unlike tag:) e. From owner-atom-syntax@mail.imc.org Thu Oct 21 20:11: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 UAA08558 for ; Thu, 21 Oct 2004 20:11: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 i9M05uIS040567; Thu, 21 Oct 2004 17:05: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 i9M05uu8040566; Thu, 21 Oct 2004 17:05:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9M05bGh040449; Thu, 21 Oct 2004 17:05:38 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 21 Oct 2004 17:05:42 -0700 To: Eric Scheid , Atom Syntax From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-atompub-format-03.txt 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 9:43 AM +1000 10/22/04, Eric Scheid wrote: > > vemmi://example.org/2003/32397 > >the vemmi URI scheme is described here: > >http://www.rfc-archive.org/getrfc.php?rfc=2122 > >an odd choice for an URI (albeit it is actually supported with an RFC, >unlike tag:) That's a very nice feature, yes. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Oct 21 20:11:47 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 UAA08700 for ; Thu, 21 Oct 2004 20:11:46 -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 i9M04aum040170; Thu, 21 Oct 2004 17:04:36 -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 i9M04aOv040169; Thu, 21 Oct 2004 17:04:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9M04XW1040146; Thu, 21 Oct 2004 17:04:34 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <3f1451f504102113326265c37a@mail.gmail.com> References: <3f1451f504102113326265c37a@mail.gmail.com> Date: Thu, 21 Oct 2004 17:04:39 -0700 To: Joe Gregorio , Atom Syntax From: Paul Hoffman / IMC Subject: Re: RFC2396bis now a Full Standard 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 4:32 PM -0400 10/21/04, Joe Gregorio wrote: >Given that RFC2396bis is now a full standard should we update the >format and publication protocol specs to follow? Yes, definitely. It probably won't get its RFC number for a few months, but it is certainly safe for us to reference it as if it will. That is, it will get its RFC number before we will. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Oct 21 20:24:16 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 UAA11310 for ; Thu, 21 Oct 2004 20:24:15 -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 i9M0IilF043406; Thu, 21 Oct 2004 17:18: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 i9M0IiCO043405; Thu, 21 Oct 2004 17:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9M0IhMT043382 for ; Thu, 21 Oct 2004 17:18:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 22 Oct 2004 10:18:56 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 22 Oct 2004 10:18:46 +1000 Subject: multiple alternates? From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Spotted in the latest spec [1], but it's not new to this version... > 5.2 "atom:link" Element > > atom:entry elements MUST NOT contain more than one atom:link element with a > rel attribute value of "alternate" that has the same type attribute value. > what if I have multiple alternates, all in text/html, but in different languages? according to the spec, this would be in error: attribute value and hreflang attribute value. (do we need a Pace for that?) e. [1] http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html From owner-atom-syntax@mail.imc.org Thu Oct 21 21:02: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 VAA18281 for ; Thu, 21 Oct 2004 21:02: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 i9M0raWq051563; Thu, 21 Oct 2004 17:53:36 -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 i9M0raOv051562; Thu, 21 Oct 2004 17:53:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9M0rYeQ051556 for ; Thu, 21 Oct 2004 17:53:35 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 22 Oct 2004 10:53:47 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 22 Oct 2004 10:53:38 +1000 Subject: Re: I-D ACTION:draft-ietf-atompub-format-03.txt From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200410211932.PAA10763@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit reading the diff, some nits specific to the update... ----------------------------------------------------- > 3.1.1 "type" Attribute (Text Constructs) > > If the value of "type" is "XHTML", the content of the Text construct MAY > contain child elements. The content SHOULD be XHTML text and markup that > could validly appear directly within an xhtml:div element. Receiving software > which displays the content MAY use the markup to aid in displaying it. > while text constructs with @type=HTML 'must be encoded' (shouldn't that be 'MUST be encoded'?), the spec is silent of whether text constructs with @type=XHTML can/should/not be encoded. will this be a problem? (was there discussion and changing the name of this attribute away from 'type'? possibly 'mode'?) ----------------------------------------------------- > 3.2 Person Constructs > > This specification assigns no significance to the order of appearance of the > child elements of atom:entry. > copy/paste-o? ----------------------------------------------------- > 3.5 Link Constructs > > A Link construct is an empty element that describes a connection from an Atom > document to another Web resource. > what is "an Atom document" here - is it this particular instantiation of the feed, or can it also refer to individual entries (or other constructs?) within said feed document? That is, is the a connection from the full document, or is it a connection from the enclosing Atom element (entry, person, generator?) ----------------------------------------------------- > The "atom:copyright" element is Text construct that conveys a human-readable > copyright statement for the feed. atom:head elements MAY contain an > atom:copyright element, but MUST NOT contain more than one. > > [[Is the following paragraph bogus amateur lawyering? The first paragraph > seems sufficient.]] > > The atom:copyright element may be assumed to apply to all entries contained > by the feed except those entries which contain atom:copyright elements. The > atom:copyright element MUST, if present, be considered to apply to the feed > as a collection of entries. This paragraph is making two points: (a) the precedence of entry/copyright over head/copyright, and (b) the continuing applicability of head/copyright to the collection of entries (even if every entry has it's own copyright element). Both are good points worth making. ----------------------------------------------------- > 5.9 "atom:summary" Element > > atom:entry elements MUST contain an atom:summary element in any of > the following cases: > > o the atom:entry contains content which is encoded in Base64; i.e. > the "type" attribute of atom:content is a MIME media type > [RFC2045] and does not begin with "text/" nor end with "+xml". We've changed the semantics/syntax of content/@type to include TEXT, HTML, and XHTML as special meaning tokens, and of course entries with content of of any of those three types don't "require" atom/summary. This makes the above case logically inconsistent with the "i.e." assertion. ----------------------------------------------------- e. From owner-atom-syntax@mail.imc.org Fri Oct 22 07:44:26 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 HAA25449 for ; Fri, 22 Oct 2004 07:44: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 i9MBRVS3009232; Fri, 22 Oct 2004 04:27:31 -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 i9MBRVQF009231; Fri, 22 Oct 2004 04:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MBRU5Q009169 for ; Fri, 22 Oct 2004 04:27:30 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so67468rnb for ; Fri, 22 Oct 2004 04:27:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=TwImGqYUPNmmamSATEsHt/Z2zx7Kz1qddEH+66a1YAyKXtP+w7fLKTjT96XGtRMIU0AcC3k4/syNas4OqfeWoLXKNE8xgdQXCo/CzY91YHnb4cwcyyUq2gzHeDlWFvMv9hvhTXmGr1dZeGVVTm0Igc9yDUJzDXoQI6jaIb83JIc= Received: by 10.38.8.2 with SMTP id 2mr613959rnh; Fri, 22 Oct 2004 04:27:26 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 22 Oct 2004 04:27:26 -0700 (PDT) Message-ID: <1f2ed5cd041022042798287d5@mail.gmail.com> Date: Fri, 22 Oct 2004 13:27:26 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Referencing entry URI from content Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just a thought - If "It's the Entries, Stupid!", then it doesn't seem unreasonable for the content to be able to carry a reference back to the entry. Is there any way this could work? Just to clarify what I mean, here's a strawman with the kindling pre-lit - the entry has a URI, so presumably that would be an appropriate hook: http://example.org When passed to subsequent processing, the content would appear as: The templating kind of approach here suggests one kind of situation in which it might be useful, another would be in a possible approach to extensibility, in which characteristics of the entry could be described within the content, by reference back to the entry id. Relative XPaths may be a possible approach, only that seems even more fragile than the technique above. I'm not really suggesting this is a requirement, just that if it were possible to achieve painlessly, it could well be useful. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 22 14:25:19 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 OAA26773 for ; Fri, 22 Oct 2004 14:25:19 -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 i9MI9c76077678; Fri, 22 Oct 2004 11:09:38 -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 i9MI9c00077677; Fri, 22 Oct 2004 11:09:38 -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 i9MI9cDZ077670 for ; Fri, 22 Oct 2004 11:09:38 -0700 (PDT) (envelope-from dorchard@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i9MI9bZR028548; Fri, 22 Oct 2004 11:09:37 -0700 Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Oct 2004 11:09:37 -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="us-ascii" Subject: RE: Referencing entry URI from content Date: Fri, 22 Oct 2004 11:09:36 -0700 Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0B2DD0AA@ussjex01.amer.bea.com> Thread-Topic: Referencing entry URI from content Thread-Index: AcS4Ko6NSZK0Ykj7RXehCjd+S6tPyAAN4uig From: "David Orchard" To: "Danny Ayers" , X-OriginalArrivalTime: 22 Oct 2004 18:09:37.0627 (UTC) FILETIME=[4AE872B0:01C4B862] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9MI9cDZ077672 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This seems vaguely like XInclude for attributes. Dave > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] On Behalf Of Danny Ayers > Sent: Friday, October 22, 2004 4:27 AM > To: atom-syntax@imc.org > Subject: Referencing entry URI from content > > > Just a thought - > > If "It's the Entries, Stupid!", then it doesn't seem unreasonable for > the content to be able to carry a reference back to the entry. Is > there any way this could work? > > Just to clarify what I mean, here's a strawman with the kindling > pre-lit - the entry has a URI, so presumably that would be an > appropriate hook: > > > http://example.org > > > > > > When passed to subsequent processing, the content would appear as: > > > > The templating kind of approach here suggests one kind of situation in > which it might be useful, another would be in a possible approach to > extensibility, in which characteristics of the entry could be > described within the content, by reference back to the entry id. > > Relative XPaths may be a possible approach, only that seems even more > fragile than the technique above. > > I'm not really suggesting this is a requirement, just that if it were > possible to achieve painlessly, it could well be useful. > > Cheers, > Danny. > > -- > > http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 22 15:25: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 PAA02233 for ; Fri, 22 Oct 2004 15:25: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 i9MJImBR087584; Fri, 22 Oct 2004 12:18: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 i9MJIms1087583; Fri, 22 Oct 2004 12:18:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MJIlqg087521 for ; Fri, 22 Oct 2004 12:18:47 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.100.54] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9MIeOSf012194 for ; Fri, 22 Oct 2004 19:40:29 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200410211932.PAA10763@ietf.org> References: <200410211932.PAA10763@ietf.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--95860550; protocol="application/pkcs7-signature" Message-Id: From: Graham Subject: Re: I-D ACTION:draft-ietf-atompub-format-03.txt Date: Fri, 22 Oct 2004 19:40:22 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6--95860550 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I see the wording of atom:origin is still nonsense: The "atom:origin" element's content conveys the original source of the entry; e.g., the feed where the entry was first published. If the source is an Atom Feed Document, then the content of atom:origin MUST be the same, character-for-character, as [etc] But there's no "If not...". I think it's meant to imply that you only ever use atom:origin when the source is an Atom Feed Document, in which case the "If the source is an Atom Feed Document" needs to be in the first paragraph. eg: The "atom:origin" element's content conveys the original source of the entry when the source is an Atom Feed Document; e.g., the feed where the entry was first published. The content of atom:origin MUST be the same, character-for-character, as [etc] Is that the intended meaning? (The "e.g." probably then needs changing to "i.e") Graham --Apple-Mail-6--95860550 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDIyMTg0MDIzWjAjBgkqhkiG9w0BCQQxFgQUUWKAvZjagE7WqBQSOT8M/rW5 pyIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAKxdN7vERqMURGYny1kIgEads a7XhVogKiCtZslDXqWRP0nduK0Qm9PJzpjFjq2oRIVwoqCtHIu7WCRVRelx9yR2wDYVLydtLobZm P17++Q+08OwrCg8B+iZx7W+LHg8l2Hb5RVhRqcvJ3yF14peJerIExD+mqzOI42qBFn4AIRBacHLP TvwHzP52mbbmFlQmzpgifKPXLPBOdvQqY2HDTnFOjwdOD0YPa1qX7pQ6CwY9oPRUfz1NuiqfArIA Z/y7D74ZeZmkB3PuelFyrhKhvPCX8o+UERThTPFQNu1i6lJ+xTZYHD5Ub8PGsAkcJsegmCa0OtKL Iq771ba9dM9HegAAAAAAAA== --Apple-Mail-6--95860550-- From owner-atom-syntax@mail.imc.org Fri Oct 22 16:13:50 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 QAA06759 for ; Fri, 22 Oct 2004 16:13:49 -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 i9MK40N1095633; Fri, 22 Oct 2004 13:04:00 -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 i9MK40Wg095632; Fri, 22 Oct 2004 13:04:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MK3ws7095624; Fri, 22 Oct 2004 13:03:59 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: <200410211932.PAA10763@ietf.org> Date: Fri, 22 Oct 2004 13:03:59 -0700 To: Graham , Atom Syntax From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-atompub-format-03.txt 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 7:40 PM +0100 10/22/04, Graham wrote: >I see the wording of atom:origin is still nonsense: > > The "atom:origin" element's content conveys the original source of > the entry; e.g., the feed where the entry was first published. > > If the source is an Atom Feed Document, then the content of atom:origin > MUST be the same, character-for-character, as [etc] > >But there's no "If not...". I think it's meant to imply that you >only ever use atom:origin when the source is an Atom Feed Document, >in which case the "If the source is an Atom Feed Document" needs to >be in the first paragraph. > >eg: > The "atom:origin" element's content conveys the original source of > the entry when the source is an Atom Feed Document; e.g., the >feed where the entry > was first published. > > The content of atom:origin MUST be the same, >character-for-character, as [etc] > >Is that the intended meaning? That sounds right to me from looking at the discussion. > (The "e.g." probably then needs changing to "i.e") Or, to make it more clear, "that is". --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Oct 22 16:48:44 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 QAA13106 for ; Fri, 22 Oct 2004 16:48:43 -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 i9MKgBWQ004961; Fri, 22 Oct 2004 13:42:11 -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 i9MKgBQR004960; Fri, 22 Oct 2004 13:42:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MKgAEW004900 for ; Fri, 22 Oct 2004 13:42:10 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by stewie.corp.google.com (8.12.11/8.12.11) with ESMTP id i9MKfwCn020265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Oct 2004 13:41:58 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1CL6EY-0002U7-5k by authid for ; Fri, 22 Oct 2004 13:41:58 -0700 Date: Fri, 22 Oct 2004 13:41:58 -0700 From: Greg Stein To: atom-syntax@imc.org Subject: Re: namespaced extensibility - some problems in practice Message-ID: <20041022204158.GA19301@google.com> References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2ed5cd041021105117b4597b@mail.gmail.com> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 21, 2004 at 07:51:13PM +0200, Danny Ayers wrote: >... > Yep, ok. But I'd suggest this is generally a good thing on the Web, > because it allows independent, decentralized development to take place > while maintaining a consistent global whole. I'm not even sure why there is a discussion. There is no way that we can or would want to centrally-manage extensions. And I can't imagine that people who want to provide customization would want to go through the hoops. In my case, if we find something that makes sense for Blogger to put into the feed, then we'll just do that. And we'll document that extension so that people can consume it and/or follow the same pattern with their feeds. A registry of extensions that people have made would be just fine, but central management would be poor... Cheers, -g From owner-atom-syntax@mail.imc.org Fri Oct 22 17:47:13 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 RAA25059 for ; Fri, 22 Oct 2004 17:47:13 -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 i9MLcWaM018418; Fri, 22 Oct 2004 14:38: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 i9MLcWIe018417; Fri, 22 Oct 2004 14:38:32 -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 i9MLcVb5018407 for ; Fri, 22 Oct 2004 14:38:31 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.3]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CL81G-0005nU-PI; Fri, 22 Oct 2004 22:36:22 +0000 Message-ID: <41797DE6.3000704@franklinmint.fm> Date: Fri, 22 Oct 2004 17:38:46 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid , Graham CC: Atom Syntax Subject: format-03 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thank you for taking the time to inspect. Graham wrote: > I see the wording of atom:origin is still nonsense Our nonsense fidelity is so high, the atom:origin text survived numerous round trips. Anyway, noted. We'll get it next time. Eric Scheid wrote: > > while text constructs with @type=HTML 'must be encoded' (shouldn't that be > 'MUST be encoded'?), the spec is silent of whether text constructs with > @type=XHTML can/should/not be encoded. > Definitely a nit, but I agree it is a bit fuzzy. It's implied that XHTML Text constructs are not encoded since it is allowed to have child elements. > > >>3.2 Person Constructs >> >>This specification assigns no significance to the order of appearance of the >>child elements of atom:entry. >> > > copy/paste-o? Yes. > > >>3.5 Link Constructs >> >>A Link construct is an empty element that describes a connection from an Atom >>document to another Web resource. >> > > what is "an Atom document" here Atom Documents are described in section 2. I suppose it should be capitalized here. The exact relation would be more obvious if we decided just where properties go. >> >>[[Is the following paragraph bogus amateur lawyering? The first paragraph >>seems sufficient.]] >> ... > > This paragraph is making two points: (a) the precedence of entry/copyright > over head/copyright, and (b) the continuing applicability of head/copyright > to the collection of entries (even if every entry has it's own copyright > element). Both are good points worth making. > Both good points worth making when writing copyright laws. IMHO, it is sufficient to say that that head/copyright applies to the feed, while entry/copyright applies to the entry. Copyright concerns about collected works are for the courts. >> >>atom:entry elements MUST contain an atom:summary element in any of >> the following cases: >> >> o the atom:entry contains content which is encoded in Base64; i.e. >> the "type" attribute of atom:content is a MIME media type >> [RFC2045] and does not begin with "text/" nor end with "+xml". > > > We've changed the semantics/syntax of content/@type to include TEXT, HTML, > and XHTML as special meaning tokens, and of course entries with content of > of any of those three types don't "require" atom/summary. This makes the > above case logically inconsistent with the "i.e." assertion. This comment seems to be incorrect. Or maybe I just don't get it. Show me an example if that's the case. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 22 17:56:40 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 RAA26472 for ; Fri, 22 Oct 2004 17:56:39 -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 i9MLpiX0021986; Fri, 22 Oct 2004 14: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 i9MLpiJk021985; Fri, 22 Oct 2004 14:51:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MLphg4021979 for ; Fri, 22 Oct 2004 14:51:44 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20041022204158.GA19301@google.com> References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> Date: Fri, 22 Oct 2004 14:51:45 -0700 To: atom-syntax@imc.org From: Paul Hoffman / IMC Subject: Re: namespaced extensibility - some problems in practice 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 1:41 PM -0700 10/22/04, Greg Stein wrote: >A registry of extensions that people have made would be just fine, but >central management would be poor... Any registry on the Internet *has* to be managed; otherwise it will get filled with garbage, particularly spam from people who want to raise their ranking in Google^Wvarious search engines. There has to be some human-controlled gating function, even if it is very very low. If there is to be one registry (as compared to many "here are the extensions I've seen and what I think I have heard they mean" pages), it has to be findable by developers. Another option is to mandate that the namespace URIs point to descriptions of the extensions. That might work, but probably not very well, and probably not for very long. FWIW, I'm *not* saying that, if we pick a single registry, we need to use IANA. If we don't, we are probably going to end up inventing something with IANA-like rules and less visibility and assurance of longevity and openness. There could be good reasons for doing that, but I don't see any yet. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Oct 22 18:38:22 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 SAA04986 for ; Fri, 22 Oct 2004 18:38: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 i9MMWKEn029581; Fri, 22 Oct 2004 15:32: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 i9MMWKAC029580; Fri, 22 Oct 2004 15:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MMWJQd029574 for ; Fri, 22 Oct 2004 15:32:19 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 23 Oct 2004 08:32:30 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 23 Oct 2004 08:30:57 +1000 Subject: Re: format-03 comments From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41797DE6.3000704@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23/10/04 7:38 AM, "Robert Sayre" wrote: >>> o the atom:entry contains content which is encoded in Base64; i.e. >>> the "type" attribute of atom:content is a MIME media type >>> [RFC2045] and does not begin with "text/" nor end with "+xml". >> >> >> We've changed the semantics/syntax of content/@type to include TEXT, HTML, >> and XHTML as special meaning tokens, and of course entries with content of >> of any of those three types don't "require" atom/summary. This makes the >> above case logically inconsistent with the "i.e." assertion. > > This comment seems to be incorrect. Or maybe I just don't get it. Show > me an example if that's the case. you're right, I mis-read. The TEXT/HTML/XHTML @type values are not MIME media types, and thus not covered by the final clause. e. From owner-atom-syntax@mail.imc.org Fri Oct 22 21:08:43 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 VAA19660 for ; Fri, 22 Oct 2004 21:08:42 -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 i9N11Rrj055010; Fri, 22 Oct 2004 18:01:27 -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 i9N11R5e055009; Fri, 22 Oct 2004 18:01:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9N11RfU054976; Fri, 22 Oct 2004 18:01:27 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by nappa.corp.google.com (8.12.11/8.12.11) with ESMTP id i9N11NN4001098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Oct 2004 18:01:23 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1CLAHb-0003Q5-Ou by authid ; Fri, 22 Oct 2004 18:01:23 -0700 Date: Fri, 22 Oct 2004 18:01:23 -0700 From: Greg Stein To: Paul Hoffman / IMC Cc: atom-syntax@imc.org Subject: Re: namespaced extensibility - some problems in practice Message-ID: <20041023010123.GB19301@google.com> References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Oct 22, 2004 at 02:51:45PM -0700, Paul Hoffman / IMC wrote: > > At 1:41 PM -0700 10/22/04, Greg Stein wrote: > >A registry of extensions that people have made would be just fine, but > >central management would be poor... > > Any registry on the Internet *has* to be managed; otherwise it will Sorry... I wasn't clear. I meant "managed" as in, "you must do X and Y to appear in this registry and (thus) be a legal extension." i.e. some kind of gating function to how people can extend. I'm a strong proponent of letting people use their creativity to extend things *without* a central authority overseeing how a standard is extended. I would not like to see a damper on that. [ and I might note that Atom started *because* we wanted to avoid a centrally-managed right to extend ] > get filled with garbage, particularly spam from people who want to > raise their ranking in Google^Wvarious search engines. There has to > be some human-controlled gating function, even if it is very very low. Agreed. > If there is to be one registry (as compared to many "here are the > extensions I've seen and what I think I have heard they mean" pages), > it has to be findable by developers. Sure. Today's search engines do very well from this standpoint. It is very easy to find the "locus" of development efforts around any standard, project, or other kind of specification. From there, it is hopefully very easy to link to the central registry which describes/links to specs on how people have extended. > Another option is to mandate that the namespace URIs point to > descriptions of the extensions. That might work, but probably not > very well, and probably not for very long. I would suggest that the namespaces remain just that: URIs. I don't think they should be URLs, and thus, not resolvable to any meaningful info. It is rather constraining to state that a namespace URI must be a locator. Cheers, -g From owner-atom-syntax@mail.imc.org Fri Oct 22 21:51:11 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 VAA21835 for ; Fri, 22 Oct 2004 21:51:11 -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 i9N1hYj0063192; Fri, 22 Oct 2004 18:43: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 i9N1hYGt063191; Fri, 22 Oct 2004 18:43:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9N1hXgY063174 for ; Fri, 22 Oct 2004 18:43:34 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id 75so438986rnl for ; Fri, 22 Oct 2004 18:43:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Fq67ZpDMKi38gL/y/AqqjyHvM/f90RWZxxxPgImg68+9MB2b8n04trEdJwzqT2p4UPKhGW58BVijp6jFJ5PRYOCjTti3Ph9ptJdkkDUWuvYZYDkFO5P6yI0IR358htSJjgjFq8MgI25Ro3KbOB4gkWVvhUYyVoolrtJTBJNuv9I= Received: by 10.38.152.74 with SMTP id z74mr15991rnd; Fri, 22 Oct 2004 18:43:40 -0700 (PDT) Received: by 10.38.151.74 with HTTP; Fri, 22 Oct 2004 18:43:40 -0700 (PDT) Message-ID: <3f1451f504102218433bc3dab@mail.gmail.com> Date: Fri, 22 Oct 2004 21:43:40 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Greg Stein , Sam Ruby Subject: Re: namespaced extensibility - some problems in practice Cc: Paul Hoffman / IMC , atom-syntax@imc.org In-Reply-To: <20041023010123.GB19301@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> <20041023010123.GB19301@google.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 22 Oct 2004 18:01:23 -0700, Greg Stein wrote: > > On Fri, Oct 22, 2004 at 02:51:45PM -0700, Paul Hoffman / IMC wrote: > > Another option is to mandate that the namespace URIs point to > > descriptions of the extensions. That might work, but probably not > > very well, and probably not for very long. > > I would suggest that the namespaces remain just that: URIs. I don't think > they should be URLs, and thus, not resolvable to any meaningful info. It > is rather constraining to state that a namespace URI must be a locator. Which is why PURL[1] is such a great service. So good in fact that we use in in Atom today: xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-03 Unfortunately it appears that our space on purl.org has fallen into disrepair, since that URI comes up as a 404. If we end up using URIs the use of PURL is something that should go into the "best practices" document, along with keeping them current ;) [1] http://purl.org/ -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Oct 22 22:39:55 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 WAA05867 for ; Fri, 22 Oct 2004 22:39:55 -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 i9N2XqYP073347; Fri, 22 Oct 2004 19:33: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 i9N2XqNI073346; Fri, 22 Oct 2004 19:33:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9N2XoMS073339; Fri, 22 Oct 2004 19:33:50 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20041023010123.GB19301@google.com> References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> <20041023010123.GB19301@google.com> Date: Fri, 22 Oct 2004 19:33:52 -0700 To: Greg Stein From: Paul Hoffman / IMC Subject: Re: namespaced extensibility - some problems in practice Cc: atom-syntax@imc.org 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 6:01 PM -0700 10/22/04, Greg Stein wrote: >On Fri, Oct 22, 2004 at 02:51:45PM -0700, Paul Hoffman / IMC wrote: >> >> At 1:41 PM -0700 10/22/04, Greg Stein wrote: >> >A registry of extensions that people have made would be just fine, but >> >central management would be poor... >> >> Any registry on the Internet *has* to be managed; otherwise it will > >Sorry... I wasn't clear. I meant "managed" as in, "you must do X and Y to >appear in this registry and (thus) be a legal extension." i.e. some kind >of gating function to how people can extend. And I still contend that you need an X and a Y and a Z, even if it is a very low bar. It can be as low as X="fill out an online form properly", and Y="have it be readable to at least one human on the registry team", and Z="make it an extension actually relevant to Atom". Without Y, you won't be able to tell whether the thing in the unknown language is spam or is a request for a copy of the Atom spec or some such thing. Without Z, you will be a magnet for folks who have a less firm grip on reality than you would want in the person sitting next to you on the bus. Seriously. >I'm a strong proponent of letting people use their creativity to extend >things *without* a central authority overseeing how a standard is >extended. I would not like to see a damper on that. Agree. But you still have to put some restrictions on the registry. And you will certainly hear from some of the folks who fail the Z test what a bunch of you are. >[ and I might note that Atom started *because* we wanted to avoid a > centrally-managed right to extend ] With essentially any IETF protocol, one *always* has the right to extent. The registry is so that the extensions can be interoperable. > > If there is to be one registry (as compared to many "here are the >> extensions I've seen and what I think I have heard they mean" pages), >> it has to be findable by developers. > >Sure. Today's search engines do very well from this standpoint. It is very >easy to find the "locus" of development efforts around any standard, >project, or other kind of specification. You maybe overestimate the value of your company's service. :-) You certainly overestimate the ability of typical developers ten years after a standard is made to understand search engine result. But it can be done. > From there, it is hopefully very >easy to link to the central registry which describes/links to specs on how >people have extended. If they feel like it. Remember, many industries often have two or more competing trade associations; Atom could easily have this "feature". --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Oct 22 22:53: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 WAA06471 for ; Fri, 22 Oct 2004 22:53:34 -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 i9N2mmXi076110; Fri, 22 Oct 2004 19:48: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 i9N2mm0c076109; Fri, 22 Oct 2004 19:48:48 -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 i9N2mmbx076074; Fri, 22 Oct 2004 19:48:48 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=[192.168.1.103]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CLBxb-0005qY-A3; Sat, 23 Oct 2004 02:48:51 +0000 Message-ID: <4179C69C.3060704@franklinmint.fm> Date: Fri, 22 Oct 2004 22:49:00 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Greg Stein , atom-syntax@imc.org Subject: Re: namespaced extensibility - some problems in practice References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> <20041023010123.GB19301@google.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At 6:01 PM -0700 10/22/04, Greg Stein wrote: > >> >> Sorry... I wasn't clear. I meant "managed" as in, "you must do X and Y to >> appear in this registry and (thus) be a legal extension." i.e. some kind >> of gating function to how people can extend. > > > And I still contend that you need an X and a Y and a Z, even if it is a > very low bar. It can be as low as X="fill out an online form properly", > and Y="have it be readable to at least one human on the registry team", > and Z="make it an extension actually relevant to Atom". > I think Greg is against disallowing private extension. I don't think Paul's ideas here disallow them. A registry for "approved extensions" seems like a good idea, but "approved extensions" don't make a lot of sense if they haven't been tried outside of someone's LAN before being approved. I think the the concept being proposed is "Register extensions with _____ to ensure interoperability and communication." Makes sense to me. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 23 08:29: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 IAA22725 for ; Sat, 23 Oct 2004 08:29: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 i9NCCJsr080388; Sat, 23 Oct 2004 05:12: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 i9NCCJNT080387; Sat, 23 Oct 2004 05:12:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NCCH64080375 for ; Sat, 23 Oct 2004 05:12:18 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so123250rnb for ; Sat, 23 Oct 2004 05:12:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XdcXdeEeCmobTW3rDAIiFl8iehkud6w0VwPiTqJDkOog406HF8iriTRq+Kcx2W/3TT5SWsYVtXvaFowGtxiNUMb4/BvtOZK9VgJ18mq6+EyqQ3ULcQLeKitwoL46g7EL+KLvx/t+a7ttdiwsoVfYGi2H34SpfefHXDAY6dWGwXY= Received: by 10.38.98.30 with SMTP id v30mr1070344rnb; Sat, 23 Oct 2004 05:12:19 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 23 Oct 2004 05:12:19 -0700 (PDT) Message-ID: <1f2ed5cd04102305123322da42@mail.gmail.com> Date: Sat, 23 Oct 2004 14:12:19 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: namespaced extensibility - some problems in practice Cc: Paul Hoffman / IMC , Greg Stein , atom-syntax@imc.org In-Reply-To: <4179C69C.3060704@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> <20041023010123.GB19301@google.com> <4179C69C.3060704@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg: >I'm a strong proponent of letting people use their creativity to extend >things *without* a central authority overseeing how a standard is >extended. I would not like to see a damper on that. Paul: Agree. But you still have to put some restrictions on the registry. Robert: > A registry for "approved extensions" seems like a good idea, but > "approved extensions" don't make a lot of sense if they haven't been > tried outside of someone's LAN before being approved. > > I think the the concept being proposed is > > "Register extensions with _____ to ensure interoperability and > communication." > > Makes sense to me. It /almost/ makes sense to me. The notion of extension approval by committee does strike me as a potential damper on innovation. The test of approval /should/ be whether or not people find them useful and deploy them, but that leads to a chicken & egg situation. Ok, some limited editorial-style control over a registry may be needed in practice, but the main control should be technical, i.e. spec-conformance. The best way to implement that in a fair way would be to produce a checklist of characteristics. Among those requirements could be measures of age and deployment. Any extension may fulfil the requirement on the checklist, all extensions listed in the registry MUST fulfil those requirements. You may be interested in a little research I did on what is the nearest thing to a registry of RSS 2.0 extensions last year (skip the crit of Tim!) : http://dannyayers.com/archives/2003/08/12/bray-and-namespaces/ Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 23 12:06: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 MAA05804 for ; Sat, 23 Oct 2004 12:06: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 i9NFv7N8097675; Sat, 23 Oct 2004 08:57:07 -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 i9NFv72E097674; Sat, 23 Oct 2004 08:57:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NFurEd097613; Sat, 23 Oct 2004 08:56:54 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd04102305123322da42@mail.gmail.com> <4179C69C.3060704@franklinmint.fm> References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> <20041023010123.GB19301@google.com> <4179C69C.3060704@franklinmint.fm> <1f2ed5cd04102305123322da42@mail.gmail.com> <4179C69C.3060704@franklinmint.fm> Date: Sat, 23 Oct 2004 08:56:56 -0700 To: Robert Sayre , Danny Ayers From: Paul Hoffman / IMC Subject: Re: namespaced extensibility - some problems in practice Cc: Greg Stein , atom-syntax@imc.org 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:49 PM -0400 10/22/04, Robert Sayre wrote: >I think Greg is against disallowing private extension. I don't think >Paul's ideas here disallow them. Completely correct. A registry helps interoperability, but in no way prevents anyone from emitting or accepting any extension. A very obvious example is a human-language-specific extension for a language that is not spoken by the registry. For those of you who have curled up with the Unicode standard, this is not that far-fetched of an example. Some written languages have what most of us would consider "weird" display issues. Someone might create an extension for display of one part of an Atom entry if it is that language. They could care less if anyone else understood the language, so they write up the description of it in their own language. They can't register that because the registrar can't read it, but it is still a 100% valid Atom extension. There are plenty of other scenarios where there are extensions that would not be registered. >A registry for "approved extensions" seems like a good idea, but >"approved extensions" don't make a lot of sense if they haven't been >tried outside of someone's LAN before being approved. Disagree. A reasonable registry could simply be a repository of the extension-writer's descriptions with no testing at all. It just says "if you see this namespace tag, I meant this". This policy has the positive side-effect of pissing off fewer people because more people can get their extensions registered. At 2:12 PM +0200 10/23/04, Danny Ayers wrote: >The notion of extension approval by committee does strike me as a >potential damper on innovation. Fully agree. > The test of approval /should/ be >whether or not people find them useful and deploy them, but that leads >to a chicken & egg situation. Nope, not even that far. If the test is limited to "is it legible and on-topic", that is sufficient. There will be (approximately) two types of developers: - Ones who want to read the whole registry when they start, looking for extensions they should handle - Ones who watch real-world streams looking for which extensions exist in the wild The first group might be disappointed to see a huge registry, but no one is forcing them to read everything. As long as the registry is skimmable, these folks should be OK. For the second group, as long as the registry contains everything they see in real-world streams, they're happy. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Oct 23 13:13:47 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 NAA09909 for ; Sat, 23 Oct 2004 13:13:47 -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 i9NH7l3t016781; Sat, 23 Oct 2004 10:07:47 -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 i9NH7lV6016780; Sat, 23 Oct 2004 10:07:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NH7l5f016773 for ; Sat, 23 Oct 2004 10:07:47 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 5993658B14 for ; Sat, 23 Oct 2004 13:07:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9NH7ov27418 for ; Sat, 23 Oct 2004 13:07:50 -0400 (EDT) Date: Sat, 23 Oct 2004 13:07:50 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: atom-syntax@imc.org Subject: atom was Re: [videoblogging] Re: Re: calling quicktime experts (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Another Atom user in need of enclosures. ---------- Forwarded message ---------- At some point in the past I attempted to figure out from the Atom gulag of wikis, mailing lists, articles, pages claiming to be specs, blog posts, etc if there was any support for an enclosure-like thing. From my survey I concluded that things were leaning strongly towards using the "related" attribute. However, from what you say it appears I was wrong, that there is no concensus and that there is not likely to be any soon. Oh well, and I thought the entropy of the universe was less than it actually is. I guess I should un-implement this feature to not make things any worse. a http://demandmedia.net/ From owner-atom-syntax@mail.imc.org Sat Oct 23 13:16:04 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 NAA09972 for ; Sat, 23 Oct 2004 13:16: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 i9NH5r3k016242; Sat, 23 Oct 2004 10:05: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 i9NH5ruP016241; Sat, 23 Oct 2004 10:05:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NH5qB5016219 for ; Sat, 23 Oct 2004 10:05:52 -0700 (PDT) (envelope-from lgonze@panix.com) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 4D7F658B2A for ; Sat, 23 Oct 2004 13:05:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by panix2.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) with ESMTP id i9NH5ru26433 for ; Sat, 23 Oct 2004 13:05:53 -0400 (EDT) Date: Sat, 23 Oct 2004 13:05:53 -0400 (EDT) From: Lucas Gonze Reply-To: lucas@gonze.com To: atom-syntax@imc.org Subject: Re: [podcasters] Re: pleading for some rss help on wordpress (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: An Atom user who has switched to RSS 2.0 because he needs enclosures. ---------- Forwarded message ---------- > --- In podcasters@yahoogroups.com, "thesportspod" > wrote: >> >> hey everyone, >> >> i love this technology like the rest of ya! i stumbled across >> podcasting a few days ago, and just recorded my second podcast. >> >> however, i'm not a sophisticated techie with this stuff, so i've >> started out simple with blogger.com. but have recognized that there >> are issues with ATOM and how the RSS syncs up, so now i'm ready to >> switch. >> >> i have an account now on godaddy, with the domain >> thsportspod.com... woohoo!... and have installed wordpress. From owner-atom-syntax@mail.imc.org Sat Oct 23 15:46: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 PAA18404 for ; Sat, 23 Oct 2004 15:46: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 i9NJaunT049995; Sat, 23 Oct 2004 12:36: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 i9NJauLJ049994; Sat, 23 Oct 2004 12:36:56 -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 i9NJar8L049925 for ; Sat, 23 Oct 2004 12:36:56 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5B2147C1F9; Sat, 23 Oct 2004 21:33:57 +0200 (CEST) Date: Sat, 23 Oct 2004 21:37:15 +0200 To: "Walter Underwood" , Atom-Syntax Subject: Re: Time to add advertising to Atom? References: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> <8238DABF92C911904BDF2D63@diva.verity.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <8238DABF92C911904BDF2D63@diva.verity.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 19 Oct 2004 15:40:42 -0700, Walter Underwood wrote: > I believe that an advertising marker should be in the Atom core or in an > extension published at the same time as the core. I think it belongs in an extension. But both Atom and RSS needs it, unless we want the format(s) to be hijacked by advertisement agencies one year or so from now, when they realize that money can be made from the world of syndication. > 1. Publishers need advertising, so we can't pretend it won't exist. Indeed. > 2. Many ad channels (Google, for example) clearly mark ads for the user, > so marked ads are acceptable to publishers. They may even be preferable, > because they avoid some kinds of inadvertant deceptive advertising. True. Hence an attribute on the atom:entry element might be something content providers are interested in applying. > 3. Automatic consumers(robots) need to be able to sort out the entries > from the ads. Ads mised in with search results is just not acceptable to > the users of search engines or profile services (pubsub.com). Correct. If content providers think this is a problem; desktop aggregators might be able to just filter out all advertisements from real content, we can suggest a server-side mechanism that registers downloaded ads which again affects how much content you'll get delivered. Such a solution would need to be login-based, of course, but it's still a solution. > Ads as unmarked entries: This puts the responsibility entirely on the > client. Welcome to the spam filtering business, again. Whohoo! No, I don't think this is a good solution. Not even for the ad agencies. > Ads as marked entries: Good for robots, also allows clients to display > a marker with the ads to distinguish them from other entries. I think this is the best solution. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Oct 23 19:03:56 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 TAA00316 for ; Sat, 23 Oct 2004 19:03:55 -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 i9NMtaLK095489; Sat, 23 Oct 2004 15:55:36 -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 i9NMtaPI095488; Sat, 23 Oct 2004 15:55:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NMtZod095472 for ; Sat, 23 Oct 2004 15:55:35 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so136875rnb for ; Sat, 23 Oct 2004 15:55:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LGXxR6iQxdeZkblErg2y9zigpOqH7Pj5mRu30h8+ik1+sBzgHdBI4Ve34SZPIdYEwykVdVQqA7mFgt0h84xdqhlD2RvCzKWHwBmrJdDaFBYYyT/wkeDfesgqlE6C2cPzdgORJKtcyTxJ0EYDf4n/kg029MPNhH7TigGQrPZfs04= Received: by 10.38.8.2 with SMTP id 2mr1184047rnh; Sat, 23 Oct 2004 15:55:38 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 23 Oct 2004 15:55:38 -0700 (PDT) Message-ID: <1f2ed5cd041023155517719c37@mail.gmail.com> Date: Sun, 24 Oct 2004 00:55:38 +0200 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Time to add advertising to Atom? Cc: Walter Underwood , Atom-Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <45224.195.243.113.249.1098183161.squirrel@webmail.cat-proof.de> <8238DABF92C911904BDF2D63@diva.verity.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9NMtZod095483 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 23 Oct 2004 21:37:15 +0200, Asbjørn Ulsberg wrote: > > Ads as marked entries: Good for robots, also allows clients to display > > a marker with the ads to distinguish them from other entries. > > I think this is the best solution. Agreed. I imagine there'll be quite a lot of bouncing around and attempts at stealth, but the unsubscribe button should damp things down (good word, damp). -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 23 22:46: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 WAA10393 for ; Sat, 23 Oct 2004 22:46:13 -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 i9O2aikg040262; Sat, 23 Oct 2004 19:36: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 i9O2aiVX040261; Sat, 23 Oct 2004 19:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m6f195e42.tmodns.net [66.94.25.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O2ahgX040205 for ; Sat, 23 Oct 2004 19:36:43 -0700 (PDT) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id AB41D99B0; Sat, 23 Oct 2004 21:33:17 -0500 (CDT) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09656-07; Sat, 23 Oct 2004 21:33:16 -0500 (CDT) Received: from BobT41 (unknown [10.254.207.250]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sat, 23 Oct 2004 21:33:16 -0500 (CDT) From: "Bob Wyman" To: "'Danny Ayers'" , "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" Cc: "'Walter Underwood'" , "'Atom-Syntax'" Subject: RE: Time to add advertising to Atom? Date: Sat, 23 Oct 2004 22:36:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1f2ed5cd041023155517719c37@mail.gmail.com> Thread-Index: AcS5VcO1jfnixKP4TyWAsJyU3jKkhQAGLbeg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20041024023317.AB41D99B0@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > I imagine there'll be quite a lot of bouncing around and > attempts at stealth, but the unsubscribe button should damp > things down (good word, damp). Please try not to make decisions about the Atom format based on quaint and out-moded ideas like "unsubscribe" being a useful mechanism to "punish" rogue publishers or eliminate unwanted data... When syndication was young, "unsubscribe" was a distinctly powerful tool, however, as the number of feeds has grown, we have gone far beyond being able to imagine people relying on having specific subscriptions to all or even a large proportion of the feeds they read. Consider the case of Robert Scoble who is famous for "reading" a vast number of feeds every day. Scoble actually reads over 3 million feeds every day! He subscribes directly to 950 or so and relies on PubSub to filter the remaining 3 million+ for him. Thus, Scoble is not directly "subscribed" to the more than a tiny number of the feeds that he "reads" -- at least, not in a way that he can "unsubscribe" to any specific feed. As more people discover the utility of matching engines like PubSub's or the search engines provided by Feedster and many others, we're going to find that fewer and fewer people actually "subscribe" to most of the feeds they read. It is very important to understand this changing dynamic in the usage of feeds and consider it carefully in the format design. The thing that is most critical is to carefully consider what, if anything, can be done in the format to reduce the need for intermediaries that you do not control to take on more responsibility for filtering content. Ideally, the intermediaries will "filter" and "select" based on purely objective measures. Objective measures will, however, rely on metadata being present. Thus, it is best to provide them with as much metadata as possible and reasonable. If the metadata isn't there or if it is consistently inaccurate or inconsistent in meaning due to under-specification, the intermediaries will be forced to make "judgment" calls to provide the filtering services that users will inevitably demand. When the intermediaries are forced to start implementing subjective measures of what is or is not an advertisement, end users will begin to lose control over the their access to content... That is not a good thing... bob wyman From owner-atom-syntax@mail.imc.org Sun Oct 24 02:28: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 CAA04456 for ; Sun, 24 Oct 2004 02:28: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 i9O6IEuA010175; Sat, 23 Oct 2004 23:18:14 -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 i9O6IE52010174; Sat, 23 Oct 2004 23:18:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O6IDx4010123 for ; Sat, 23 Oct 2004 23:18:13 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by rproxy.gmail.com with SMTP id 78so488921rnl for ; Sat, 23 Oct 2004 23:18:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=UVXLlQAEciHHuZ9avFS3ZGeXWiijPC3aDNnORkDowL+y+iu8otiCVoYYm+6OQFTBbQv656jnhkzn5yXw1l5lzt9PCCXsheEfLxcHxGBKytqg7I5tOrPFhoavAWbdoeaglwnjntall9hODjhIZkvhhXnpBA6yUrKrkmiaNXJ1slg= Received: by 10.38.171.54 with SMTP id t54mr503985rne; Sat, 23 Oct 2004 23:18:17 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Sat, 23 Oct 2004 23:18:17 -0700 (PDT) Message-ID: <540e3732041023231857a7301f@mail.gmail.com> Date: Sun, 24 Oct 2004 01:18:17 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom-Syntax Subject: Re: Time to add advertising to Atom? In-Reply-To: <20041024023317.AB41D99B0@mailrelay.t-mobile.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041023155517719c37@mail.gmail.com> <20041024023317.AB41D99B0@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > When syndication was > young, "unsubscribe" was a distinctly powerful tool, however, as the number > of feeds has grown, we have gone far beyond being able to imagine people > relying on having specific subscriptions to all or even a large proportion > of the feeds they read. Bob: "We" have gone no such place. :) Absolute control over input is the primary thing that makes syndication something more than mailing-lists-over-HTTP from the user's perspective, and it's not going anywhere. > at least, not in a way that he can "unsubscribe" to any specific feed. I'm sure you'll add that in a future version of PubSub... filtering out unwanted sources is pretty important. > we're going to find > that fewer and fewer people actually "subscribe" to most of the feeds they > read. Only among the Scoblesque infovores. Most folks crave brands, identities, and personalities, things you don't get from cross-web search results. > It is very important to understand this changing dynamic in the > usage of feeds and consider it carefully in the format design. Agreed. It's not nearly as significant a factor as you're suggesting, but it's still important. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sun Oct 24 06:17: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 GAA14873 for ; Sun, 24 Oct 2004 06:17: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 i9OA9ZFu020965; Sun, 24 Oct 2004 03:09:35 -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 i9OA9Z5d020964; Sun, 24 Oct 2004 03:09:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OA9Y1o020946 for ; Sun, 24 Oct 2004 03:09:34 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so146879rnb for ; Sun, 24 Oct 2004 03:09:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=lz0Vyh25gq15EtASlTKmVjTZyfMKuHy0d1ls7BT+h9zI0iJu2m9HzCwwUHgwcPsony09XLTJ4lPmrbntGcj0ncbPtTt01QycrAoTpuCSEUORVX5vxoyuCN49C5OKDCbg8t1rDOFpZ8L9y56PveXAwKavTrf3jsZYhzBiMMlYOEE= Received: by 10.38.179.77 with SMTP id b77mr1283171rnf; Sun, 24 Oct 2004 03:09:43 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sun, 24 Oct 2004 03:09:43 -0700 (PDT) Message-ID: <1f2ed5cd041024030962c3916a@mail.gmail.com> Date: Sun, 24 Oct 2004 12:09:43 +0200 From: Danny Ayers Reply-To: Danny Ayers To: "Roger B." Subject: Re: Time to add advertising to Atom? Cc: Atom-Syntax In-Reply-To: <540e3732041023231857a7301f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041023155517719c37@mail.gmail.com> <20041024023317.AB41D99B0@mailrelay.t-mobile.com> <540e3732041023231857a7301f@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 24 Oct 2004 01:18:17 -0500, Roger B. wrote: > > > When syndication was > > young, "unsubscribe" was a distinctly powerful tool, however, as the number > > of feeds has grown, we have gone far beyond being able to imagine people > > relying on having specific subscriptions to all or even a large proportion > > of the feeds they read. > > Bob: "We" have gone no such place. :) Absolute control over input is > the primary thing that makes syndication something more than > mailing-lists-over-HTTP from the user's perspective, and it's not > going anywhere. Absolutely. > > at least, not in a way that he can "unsubscribe" to any specific feed. > > I'm sure you'll add that in a future version of PubSub... filtering > out unwanted sources is pretty important. I don't deny that the dynamic is changing - most of my daily must-reads are now covered by a couple of 'Planets'. But one of the key pieces of metadata is the source of the feed. If one of the Planets decided to add a feed that included advertising, I would expect to be able to filter it out. If I couldn't, then I'd probably unsubscribe from that Planet as a whole and find another means of getting the information. Same goes for any other intermediary tool. > > we're going to find > > that fewer and fewer people actually "subscribe" to most of the feeds they > > read. > > Only among the Scoblesque infovores. Most folks crave brands, > identities, and personalities, things you don't get from cross-web > search results. Yep, probably be a wide range of (mixed) behaviour. > > It is very important to understand this changing dynamic in the > > usage of feeds and consider it carefully in the format design. > > Agreed. It's not nearly as significant a factor as you're suggesting, > but it's still important. Try substituting 'offensive content' in place of 'advertising' and apply the same reasoning. Per-feed filtering (aka unsubscribing) is the end-user's big gun. Any aggregate-republish service that doesn't take that into consideration will be at a disadvantage in an open market. If advertising goes in as unmarked content, then for many end users this will be lowering the signal/noise ration of the information source. Sure, this is bound to be one avenue pursued by marketeers, the blanket treatment of people as customers is found in every other media. But targetting is another marketing strategy, and providing additional metadata can potentially improve the publisher(seller)/consumer(buyer) matchmaking. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 24 09:40: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 JAA27932 for ; Sun, 24 Oct 2004 09:40: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 i9ODODQK087229; Sun, 24 Oct 2004 06:24: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 i9ODODdD087228; Sun, 24 Oct 2004 06:24:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from imo-m15.mx.aol.com (imo-m15.mx.aol.com [64.12.138.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ODOCPb087213 for ; Sun, 24 Oct 2004 06:24:12 -0700 (PDT) (envelope-from Svgdeveloper@aol.com) Received: from Svgdeveloper@aol.com by imo-m15.mx.aol.com (mail_out_v37_r3.8.) id 7.78.643ac1e1 (4410) for ; Sun, 24 Oct 2004 09:24:10 -0400 (EDT) From: Svgdeveloper@aol.com Message-ID: <78.643ac1e1.2ead06fa@aol.com> Date: Sun, 24 Oct 2004 09:24:10 EDT Subject: Re: Time to add advertising to Atom? To: atom-syntax@imc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_78.643ac1e1.2ead06fa_boundary" X-Mailer: 8.0 for Windows sub 670 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part1_78.643ac1e1.2ead06fa_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/24/2004 11:12:25 AM GMT Daylight Time, danny.ayers@gmail.com writes: > If advertising goes in as unmarked content, then for many end users > this will be lowering the signal/noise ration of the information > source. Sure, this is bound to be one avenue pursued by marketeers, > the blanket treatment of people as customers is found in every other > media. But targetting is another marketing strategy, and providing > additional metadata can potentially improve the > publisher(seller)/consumer(buyer) matchmaking. My take on this is that well-targeted advertising could be a plus. For example, on certain rapidly developing topics it would be great to get information about new relevant tools. That type of advertising might be welcome on precisely targeted feeds. For more general-purpose feeds I would want to have the granularity of control to turn advertising off for that particular feed. Perhaps that would be possible at individual feed level or, if not, a blanket setting in the user agent (analogous to blocking pop ups) would be welcome, whether on a per-feed or a blanket basis. One related question in my mind is how best (if at all) user agents will separate/display advertising content from normal content. Andrew Watt --part1_78.643ac1e1.2ead06fa_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 10/24/2004 11:12= :25 AM GMT Daylight Time, danny.ayers@gmail.com writes:

If advertising goes in as unmar= ked content, then for many end users
this will be lowering the signal/noise ration of the information
source. Sure, this is bound to be one avenue pursued by marketeers,
the blanket treatment of people as customers is found in every other
media. But targetting is another marketing strategy, and providing
additional metadata can potentially improve the
publisher(seller)/consumer(buyer) matchmaking.


My take on this is that well-targeted advertising could be a plus. For examp= le, on certain rapidly developing topics it would be great to get informatio= n about new relevant tools. That type of advertising might be welcome on pre= cisely targeted feeds.

For more general-purpose feeds I would want to have the granularity of contr= ol to turn advertising off for that particular feed. Perhaps that would be p= ossible at individual feed level or, if not, a blanket setting in the user a= gent (analogous to blocking pop ups) would be welcome, whether on a per-feed= or a blanket basis.

One related question in my mind is how best (if at all) user agents will sep= arate/display advertising content from normal content.

Andrew Watt --part1_78.643ac1e1.2ead06fa_boundary-- From owner-atom-syntax@mail.imc.org Sun Oct 24 14:53:43 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 OAA20725 for ; Sun, 24 Oct 2004 14:53:43 -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 i9OIlu7A058782; Sun, 24 Oct 2004 11:47: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 i9OIlu3d058781; Sun, 24 Oct 2004 11:47:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OIlt9C058775 for ; Sun, 24 Oct 2004 11:47:55 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9OIm7NH024821 for ; Sun, 24 Oct 2004 12:48:07 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6300HUUQW61X@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 24 Oct 2004 12:48:07 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6300DLJQW6WW@mail.sun.net> for atom-syntax@imc.org; Sun, 24 Oct 2004 12:48:06 -0600 (MDT) Date: Sun, 24 Oct 2004 11:48:40 -0700 From: Tim Bray Subject: Re: RFC2396bis now a Full Standard In-reply-to: <3f1451f504102113326265c37a@mail.gmail.com> To: Joe Gregorio Cc: Atom Syntax Message-id: <52896A3A-25ED-11D9-9657-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3f1451f504102113326265c37a@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 21, 2004, at 1:32 PM, Joe Gregorio wrote: > > Given that RFC2396bis is now a full standard should we update the > format and publication protocol specs to follow? Oh, yes please, let's do that immediately, and everyone take a moment to think kind thoughts about Roy Fielding, who did the huge amount of gruntwork required -Tim From owner-atom-syntax@mail.imc.org Sun Oct 24 14:55: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 OAA20823 for ; Sun, 24 Oct 2004 14:55: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 i9OIj0q6058122; Sun, 24 Oct 2004 11:45:00 -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 i9OIj074058118; Sun, 24 Oct 2004 11:45:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OIix47058112 for ; Sun, 24 Oct 2004 11:44:59 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9OIjBui015137 for ; Sun, 24 Oct 2004 12:45:11 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6300HSXQRA1X@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 24 Oct 2004 12:45:11 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6300DKXQR9W7@mail.sun.net> for atom-syntax@imc.org; Sun, 24 Oct 2004 12:45:10 -0600 (MDT) Date: Sun, 24 Oct 2004 11:45:43 -0700 From: Tim Bray Subject: Re: XML2004Hackathon In-reply-to: <2DC2B9B3-22CC-11D9-BE4D-000A95B09B46@google.com> To: steve jenson Cc: atom syntax list Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2DC2B9B3-22CC-11D9-BE4D-000A95B09B46@google.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 20, 2004, at 12:13 PM, steve jenson wrote: > > > Sofar, only 5 people have signed up for the Interop Hackathon at > XML2004[*]. I want to book my reservations but is this going to be > cancelled as the last IETF Meeting did? > > If so, let's put together an IRC channel and a time/date to have this > interop hackathon. It's been paid for, it's totally not gonna be canceled. There may be only 10 or so of us there, so what? But.... having an IRC channel is a good idea. -Tim From owner-atom-syntax@mail.imc.org Sun Oct 24 19:34: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 TAA10496 for ; Sun, 24 Oct 2004 19:34: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 i9ON9IUV016883; Sun, 24 Oct 2004 16:09: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 i9ON9IuG016882; Sun, 24 Oct 2004 16:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ON9HHF016849 for ; Sun, 24 Oct 2004 16:09:17 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by nappa.corp.google.com (8.12.11/8.12.11) with ESMTP id i9ON9MUZ018615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Oct 2004 16:09:22 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1CLrUI-0002oO-5E by authid ; Sun, 24 Oct 2004 16:09:22 -0700 Date: Sun, 24 Oct 2004 16:09:22 -0700 From: Greg Stein To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: XML2004Hackathon Message-ID: <20041024230922.GC19301@google.com> References: <2DC2B9B3-22CC-11D9-BE4D-000A95B09B46@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Oct 24, 2004 at 11:45:43AM -0700, Tim Bray wrote: > On Oct 20, 2004, at 12:13 PM, steve jenson wrote: > >Sofar, only 5 people have signed up for the Interop Hackathon at > >XML2004[*]. I want to book my reservations but is this going to be > >cancelled as the last IETF Meeting did? > > > >If so, let's put together an IRC channel and a time/date to have this > >interop hackathon. > > It's been paid for, it's totally not gonna be canceled. There may be > only 10 or so of us there, so what? But.... having an IRC channel is a > good idea. -Tim Because Steve has no reason to go to the conference *other* than the Atom interop. If we're going to test Blogger with one other piece of software, then it is much more preferable for Steve to pick up the phone and talk to that person. As of right now, there are only three pieces of software listed. It is *very* hard to justify Steve's time and expense for what could otherwise be accomplished with an afternoon conference call. Cheers, -g From owner-atom-syntax@mail.imc.org Sun Oct 24 21:49:48 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 VAA17970 for ; Sun, 24 Oct 2004 21:49:48 -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 i9P1b7P6048140; Sun, 24 Oct 2004 18:37:07 -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 i9P1b7sZ048138; Sun, 24 Oct 2004 18:37:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P1b6BY048125; Sun, 24 Oct 2004 18:37:06 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 1BFE34EF23; Sun, 24 Oct 2004 21:37:14 -0400 (EDT) Message-Id: <6.0.0.20.2.20041025103242.06103d70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 25 Oct 2004 10:37:06 +0900 To: Paul Hoffman / IMC , Robert Sayre , Danny Ayers From: Martin Duerst Subject: Re: namespaced extensibility - some problems in practice Cc: Greg Stein , atom-syntax@imc.org In-Reply-To: References: <1f2ed5cd041021090564943bd8@mail.gmail.com> <20041021164948.21239.qmail@web40825.mail.yahoo.com> <1f2ed5cd041021105117b4597b@mail.gmail.com> <20041022204158.GA19301@google.com> <20041023010123.GB19301@google.com> <4179C69C.3060704@franklinmint.fm> <1f2ed5cd04102305123322da42@mail.gmail.com> <4179C69C.3060704@franklinmint.fm> Mime-Version: 1.0 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 At 00:56 04/10/24, Paul Hoffman / IMC wrote: >Completely correct. A registry helps interoperability, but in no way prevents anyone from emitting or accepting any extension. > >A very obvious example is a human-language-specific extension for a language that is not spoken by the registry. For those of you who have curled up with the Unicode standard, this is not that far-fetched of an example. Some written languages have what most of us would consider "weird" display issues. Someone might create an extension for display of one part of an Atom entry if it is that language. They could care less if anyone else understood the language, so they write up the description of it in their own language. They can't register that because the registrar can't read it, but it is still a 100% valid Atom extension. There are definitely some such issues. But in general, many of them are already, and all of them they should be, covered by (X)HTML and CSS. If you know about something that's not covered there, please tell us, and let's fix it where the fix will have the widest possible outreach. Also, please note that in many cases, it's not a single language that has the same (or very simillar) problems, so defining such extensions by language may not be the best thing to do. Regards, Martin. From owner-atom-syntax@mail.imc.org Sun Oct 24 23:00: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 XAA22792 for ; Sun, 24 Oct 2004 23:00:50 -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 i9P2qGRY062784; Sun, 24 Oct 2004 19:52: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 i9P2qG5P062783; Sun, 24 Oct 2004 19:52:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P2qFjM062772 for ; Sun, 24 Oct 2004 19:52:15 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9P2qTNH019229 for ; Sun, 24 Oct 2004 20:52:29 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6400KLBDBGQ3@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 24 Oct 2004 20:52:29 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I64000MPDBG29@mail.sun.net> for atom-syntax@imc.org; Sun, 24 Oct 2004 20:52:28 -0600 (MDT) Date: Sun, 24 Oct 2004 19:53:02 -0700 From: Tim Bray Subject: Re: XML2004Hackathon In-reply-to: <20041024230922.GC19301@google.com> To: Greg Stein Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2DC2B9B3-22CC-11D9-BE4D-000A95B09B46@google.com> <20041024230922.GC19301@google.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 24, 2004, at 4:09 PM, Greg Stein wrote: > As of right now, there are only three pieces of software listed. It is > *very* hard to justify Steve's time and expense for what could > otherwise > be accomplished with an afternoon conference call. FWIW, I'm going to try to construct a client from scratch -T From owner-atom-syntax@mail.imc.org Mon Oct 25 04:44:07 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 EAA01653 for ; Mon, 25 Oct 2004 04:44: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 i9P8PCwT054965; Mon, 25 Oct 2004 01:25: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 i9P8PCOb054964; Mon, 25 Oct 2004 01:25:12 -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 i9P8PBRY054747 for ; Mon, 25 Oct 2004 01:25:11 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id F26E67C1F9; Mon, 25 Oct 2004 10:21:34 +0200 (CEST) To: "Danny Ayers" Cc: Atom-Syntax Subject: Re: Referencing entry URI from content References: <1f2ed5cd041022042798287d5@mail.gmail.com> Message-ID: Date: Mon, 25 Oct 2004 10:26:04 +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: <1f2ed5cd041022042798287d5@mail.gmail.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 22 Oct 2004 13:27:26 +0200, Danny Ayers wrote: > If "It's the Entries, Stupid!", then it doesn't seem unreasonable for > the content to be able to carry a reference back to the entry. Is > there any way this could work? I'm not sure why this would be useful.. Is it because the inner content of atom:entry can be plucked out of the atom:entry and thus needs to say which atom:id that was its parent? -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Oct 25 04:53:57 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 EAA02152 for ; Mon, 25 Oct 2004 04:53:57 -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 i9P8n1SS063223; Mon, 25 Oct 2004 01:49:01 -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 i9P8n1Ef063222; Mon, 25 Oct 2004 01:49:01 -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 i9P8mxlv063012 for ; Mon, 25 Oct 2004 01:49:00 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 471D27C1F9; Mon, 25 Oct 2004 10:45:23 +0200 (CEST) To: "Eric Scheid" Cc: Atom-Syntax Subject: Re: multiple alternates? References: Message-ID: Date: Mon, 25 Oct 2004 10:49:54 +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: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 22 Oct 2004 10:18:46 +1000, Eric Scheid wrote: > what if I have multiple alternates, all in text/html, but in different > languages? That can't be done at the moment, but this is a problem that should be fixed. > I propose changing the spec text to: > >> atom:entry elements MUST NOT contain more than one atom:link element >> with a rel attribute value of "alternate" that has the same combination >> of type attribute value and hreflang attribute value. I agree that we shold make this change (maybe with a clearer wording ;), but as you say yourself: > (do we need a Pace for that?) we probably need a pace, yes. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Mon Oct 25 07:10: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 HAA13731 for ; Mon, 25 Oct 2004 07:10:08 -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 i9PB3FYM019047; Mon, 25 Oct 2004 04:03: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 i9PB3F1q019046; Mon, 25 Oct 2004 04:03:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PB3F0N018991 for ; Mon, 25 Oct 2004 04:03:15 -0700 (PDT) (envelope-from dajobe@gmail.com) Received: by rproxy.gmail.com with SMTP id 78so634600rnl for ; Mon, 25 Oct 2004 04:03:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BrmCWyLPLW5dF/mTaTE5rJoqYvnVOtTcNXkAqYdRgmMCF7oTl9Pln7mMOgg9p6RO6HZ2n5UjZ+spy0afWSoWdmJwBkJxHj2h4Kocfr8s5ylHVuqYUiJ++Shvfhfwn3/XpHHPju5BggDChxRn4keBn6ht7BrSQQOGcDKZwfM7/3I= Received: by 10.38.171.54 with SMTP id t54mr1023991rne; Mon, 25 Oct 2004 04:03:09 -0700 (PDT) Received: by 10.38.83.35 with HTTP; Mon, 25 Oct 2004 04:03:08 -0700 (PDT) Message-ID: <8335bdf6041025040329b83d90@mail.gmail.com> Date: Mon, 25 Oct 2004 12:03:08 +0100 From: Dave Beckett Reply-To: Dave Beckett To: Tim Bray Subject: Re: XML2004Hackathon Cc: steve jenson , atom syntax list In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2DC2B9B3-22CC-11D9-BE4D-000A95B09B46@google.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 24 Oct 2004 11:45:43 -0700, Tim Bray wrote: > On Oct 20, 2004, at 12:13 PM, steve jenson wrote: > > Sofar, only 5 people have signed up for the Interop Hackathon at > > XML2004[*]. I want to book my reservations but is this going to be > > cancelled as the last IETF Meeting did? > > > > If so, let's put together an IRC channel and a time/date to have this > > interop hackathon. > > It's been paid for, it's totally not gonna be canceled. There may be > only 10 or so of us there, so what? But.... having an IRC channel is a > good idea. -Tim I've added details of the #atom channel on irc.freenode.net to the wiki page. It's a permanent and publically logged channel that I've been providing for the atom group for some months, available for use 24x7. Dave From owner-atom-syntax@mail.imc.org Mon Oct 25 08:14:59 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 IAA19725 for ; Mon, 25 Oct 2004 08:14:58 -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 i9PC7pmp030370; Mon, 25 Oct 2004 05:07:51 -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 i9PC7pAo030369; Mon, 25 Oct 2004 05:07:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PC7o1m030359 for ; Mon, 25 Oct 2004 05:07:51 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so185043rnb for ; Mon, 25 Oct 2004 05:07:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qZtparRrF/4qVgkcAYUTgvS6VSXcDbXKpf9L+cfRpP4YyzN9nq1ZRO8pcb6kcPLk6Wf66GvZH200K5rHo2v5g7cXQHCJHUgVV9Wvg87I3GE0Fk0C0ouPZxQ/5tH1r0t66bYjd6af30ymfM9pc1cRjrwdOXb5XTLGu0xAKZaKWgY= Received: by 10.38.98.30 with SMTP id v30mr1622474rnb; Mon, 25 Oct 2004 05:07:52 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 25 Oct 2004 05:07:52 -0700 (PDT) Message-ID: <1f2ed5cd041025050726e5b25f@mail.gmail.com> Date: Mon, 25 Oct 2004 14:07:52 +0200 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Referencing entry URI from content Cc: Atom-Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1f2ed5cd041022042798287d5@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9PC7p1m030361 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 25 Oct 2004 10:26:04 +0200, Asbjørn Ulsberg wrote: > On Fri, 22 Oct 2004 13:27:26 +0200, Danny Ayers > wrote: > > > If "It's the Entries, Stupid!", then it doesn't seem unreasonable for > > the content to be able to carry a reference back to the entry. Is > > there any way this could work? > > I'm not sure why this would be useful.. Is it because the inner content of > atom:entry can be plucked out of the atom:entry and thus needs to say > which atom:id that was its parent? Yep, it would enable the content to talk about it's container entry. Say the content was a full XHTML document, the would contain the renderable content, the would contain (additional) metadata. One significant piece of metadata would be the entry from whence it came. The scenario isn't unlike the fairly common RDF/XML idiom of using rdf:about="" to refer to the container resource/document (e.g. foaf:PersonlProfileDocument). If the payload of an Atom entry happened to be RDF/XML you might wish to refer to the entry id rather than the feed URI. This /could/ be embedded at the same time the element is generated/inserted but it feels like that would mean tight system coupling at the process level rather than loose coupling at the data level. I'm still not sure... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 25 08:18:38 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 IAA19899 for ; Mon, 25 Oct 2004 08:18:37 -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 i9PCDSwH030930; Mon, 25 Oct 2004 05:13: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 i9PCDS4H030929; Mon, 25 Oct 2004 05:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PCDRvx030919 for ; Mon, 25 Oct 2004 05:13:28 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so185213rnb for ; Mon, 25 Oct 2004 05:13:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=thNinadzvG+jtw5KkS5OzM4XkPSQrPQR4MfBSRGJIHzyUfs64s+J/pTPe2yHpSpGVjo7xsu/twkVPjkAwCRZdnyLb755gmpmhGP6uvxBIwH9lNQ2yPsnf/rk+TygqUxIcybdnmWDbOOBp/u5oyw9VcZGx2+fqyIaDszP5ZbxvKU= Received: by 10.38.98.30 with SMTP id v30mr1623733rnb; Mon, 25 Oct 2004 05:13:26 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 25 Oct 2004 05:13:26 -0700 (PDT) Message-ID: <1f2ed5cd04102505135010ef18@mail.gmail.com> Date: Mon, 25 Oct 2004 14:13:26 +0200 From: Danny Ayers Reply-To: Danny Ayers To: David Orchard Subject: Re: Referencing entry URI from content Cc: atom-syntax@imc.org In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF0B2DD0AA@ussjex01.amer.bea.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <32D5845A745BFB429CBDBADA57CD41AF0B2DD0AA@ussjex01.amer.bea.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks Dave, I didn't realise how far the spec had progressed (Proposed Rec.). Forgetting the subject line of this post, inclusion could be more generally useful in Atom (the full content/summary kind of split springs to mind). http://www.w3.org/TR/xinclude/ On Fri, 22 Oct 2004 11:09:36 -0700, David Orchard wrote: > This seems vaguely like XInclude for attributes. > > Dave > > > > -----Original Message----- > > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > > syntax@mail.imc.org] On Behalf Of Danny Ayers > > Sent: Friday, October 22, 2004 4:27 AM > > To: atom-syntax@imc.org > > Subject: Referencing entry URI from content > > > > > > Just a thought - > > > > If "It's the Entries, Stupid!", then it doesn't seem unreasonable for > > the content to be able to carry a reference back to the entry. Is > > there any way this could work? > > > > Just to clarify what I mean, here's a strawman with the kindling > > pre-lit - the entry has a URI, so presumably that would be an > > appropriate hook: > > > > > > http://example.org > > > > > > > > > > > > When passed to subsequent processing, the content would appear as: > > > > > > > > The templating kind of approach here suggests one kind of situation in > > which it might be useful, another would be in a possible approach to > > extensibility, in which characteristics of the entry could be > > described within the content, by reference back to the entry id. > > > > Relative XPaths may be a possible approach, only that seems even more > > fragile than the technique above. > > > > I'm not really suggesting this is a requirement, just that if it were > > possible to achieve painlessly, it could well be useful. > > > > Cheers, > > Danny. > > > > -- > > > > http://dannyayers.com > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 25 08:42: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 IAA21462 for ; Mon, 25 Oct 2004 08:42: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 i9PCZSXx033346; Mon, 25 Oct 2004 05:35: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 i9PCZSN3033345; Mon, 25 Oct 2004 05:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40801.mail.yahoo.com (web40801.mail.yahoo.com [66.218.78.178]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PCZRL4033330 for ; Mon, 25 Oct 2004 05:35:27 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041025123519.86348.qmail@web40801.mail.yahoo.com> Received: from [131.107.71.227] by web40801.mail.yahoo.com via HTTP; Mon, 25 Oct 2004 05:35:19 PDT Date: Mon, 25 Oct 2004 05:35:19 -0700 (PDT) From: Dare Obasanjo Subject: Re: Referencing entry URI from content To: Danny Ayers , "Asbjørn" Ulsberg Cc: Atom-Syntax In-Reply-To: <1f2ed5cd041025050726e5b25f@mail.gmail.com> 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: --- Danny Ayers wrote: > > > If "It's the Entries, Stupid!", then it doesn't > seem unreasonable for > > > the content to be able to carry a reference back > to the entry. Is > > > there any way this could work? It may not seem unreasonable but it doesn't seem terribly useful either. > > I'm not sure why this would be useful.. Is it > because the inner content of > > atom:entry can be plucked out of the atom:entry > and thus needs to say > > which atom:id that was its parent? > > Yep, it would enable the content to talk about it's > container entry. I can't think of a scenario where this would be practically useful. Can you provide an example of how one would use this or why they would? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-atom-syntax@mail.imc.org Mon Oct 25 11:06:38 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 LAA02751 for ; Mon, 25 Oct 2004 11:06:38 -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 i9PEuMKo046210; Mon, 25 Oct 2004 07:56:22 -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 i9PEuMau046209; Mon, 25 Oct 2004 07:56:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PEuKdq046201 for ; Mon, 25 Oct 2004 07:56:21 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 25-Oct-2004 15:56:01 +0100 From: "Mark Birbeck" To: "'Greg Stein'" Cc: , "'Tim Bray'" Subject: RE: XML2004Hackathon Date: Mon, 25 Oct 2004 15:55:53 +0100 Message-ID: <006c01c4baa2$b9ae9070$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20041024230922.GC19301@google.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9PEuMdq046204 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greg, > Because Steve has no reason to go to the conference *other* > than the Atom interop. If we're going to test Blogger with > one other piece of software, then it is much more preferable > for Steve to pick up the phone and talk to that person. > > As of right now, there are only three pieces of software listed. It is > *very* hard to justify Steve's time and expense for what > could otherwise be accomplished with an afternoon conference call. I sympathise with Google having to keep an eye on its expenses budget ;) -- and since I will not be heading for XML 2004 and the Hackathon, I thought I'd list here some of the issues with the Blogger.com Atom API. (Though if there is a way to remotely join the event on the day, we'll make every effort to do so.) Background -- we have implemented an Atom client using declarative mark-up, namely XForms [1]. During the course of this we identified a number of problems with Blogger's Atom API implementation, as follows: * GET SOAP requests don't return well-formed XML (link tags are opened but never closed). This is such a fundamental problem that I don't know how other people are managing to use your API, unless either (a) they are using SAX and so can be a bit more tolerant of errors, or (b) they do what we have to do and use the atom.xml document. * Since we can't use GET SOAP requests, then we have to use the initial feed (atom.xml) to obtain the item list. However, since there is a delay after publication before this document is updated and ready, we can't update a blog and then immediately re-request the list, we have to wait. We're hoping that this is not a problem when we are able to use the GET SOAP request. * Authentication doesn't seem to be implemented correctly, so a replay attack would be possible. * PUT SOAP requests seem to incorrectly require that certain attributes are *not* present. * atom:content wraps all text with html:div, including content that is already contained in a div, which means that if you do nothing about it you get an ever growing number of blank lines as you edit and re-edit. I hope that helps, and it would be great to see these issues solved. Regards, Mark [1] Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Mon Oct 25 12:25: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 MAA11563 for ; Mon, 25 Oct 2004 12:25: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 i9PGHE0h062614; Mon, 25 Oct 2004 09:17:14 -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 i9PGHETc062613; Mon, 25 Oct 2004 09:17:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGHDMk062604 for ; Mon, 25 Oct 2004 09:17:13 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so201120rnb for ; Mon, 25 Oct 2004 09:17:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KBaiPeLiSGvRRNksx81eac5wl8kiDWvvm6N9HRPzeN2b6oNFcRXtlcB/ReVNE05QB/QfALjpcpZ3jbAmJtfRjiPCNMcI/ybPpoP1A3y9jXgXbGymJknM6IT7C5PB/zZKSIszk1Dv5PEn3RP+kt+pW+6UWfYPkSP+sxmsIY/ysuE= Received: by 10.38.179.77 with SMTP id b77mr1681858rnf; Mon, 25 Oct 2004 09:17:04 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 25 Oct 2004 09:17:04 -0700 (PDT) Message-ID: <1f2ed5cd041025091712096584@mail.gmail.com> Date: Mon, 25 Oct 2004 18:17:04 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: Referencing entry URI from content Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom-Syntax In-Reply-To: <20041025123519.86348.qmail@web40801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041025050726e5b25f@mail.gmail.com> <20041025123519.86348.qmail@web40801.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 25 Oct 2004 05:35:19 -0700 (PDT), Dare Obasanjo wrote: > I can't think of a scenario where this would be > practically useful. Can you provide an example of how > one would use this or why they would? Couple of posts back: Say the content was a full XHTML document, the would contain the renderable content, the would contain (additional) metadata. One significant piece of metadata would be the entry from whence it came. The scenario isn't unlike the fairly common RDF/XML idiom of using rdf:about="" to refer to the container resource/document (e.g. foaf:PersonlProfileDocument). If the payload of an Atom entry happened to be RDF/XML you might wish to refer to the entry id rather than the feed URI. This /could/ be embedded at the same time the element is generated/inserted but it feels like that would mean tight system coupling at the process level rather than loose coupling at the data level. To qualify all that, from my initial post: I'm not really suggesting this is a requirement, just that if it were possible to achieve painlessly, it could well be useful. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 25 13:34: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 NAA16957 for ; Mon, 25 Oct 2004 13:34:34 -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 i9PHNn8H079529; Mon, 25 Oct 2004 10:23:49 -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 i9PHNnaF079528; Mon, 25 Oct 2004 10:23:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PHNm8b079499 for ; Mon, 25 Oct 2004 10:23:48 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so208222rnb for ; Mon, 25 Oct 2004 10:23:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XzaPigtAT7lyCfA/eBrHDcK/zZRP1zstuFCqSwUWtDPx2LVZVOykYgc22kdVaw78bsumpI+LdRF4mYJMhJWICC9dEpRGdwHnImMy2mokzErzwa+AKIbWxTr1wrIFt2C+gnszweg/WjZSRIr/viXc658sc+USNdeYSsqPrAFZKTM= Received: by 10.38.179.77 with SMTP id b77mr1696392rnf; Mon, 25 Oct 2004 10:17:08 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 25 Oct 2004 10:16:29 -0700 (PDT) Message-ID: <1f2ed5cd04102510162fc84aa0@mail.gmail.com> Date: Mon, 25 Oct 2004 19:16:29 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Mark Birbeck Subject: Re: XML2004Hackathon Cc: Greg Stein , atom-syntax@imc.org, Tim Bray In-Reply-To: <006c01c4baa2$b9ae9070$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041024230922.GC19301@google.com> <006c01c4baa2$b9ae9070$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On the subject of blogger.com Atom, I also tried unsuccessfully to get a SOAP client to work, as have others, check this blog post (especially comments): http://dannyayers.com/archives/2004/10/02/it-just-works/ It sounds like Mark was able to get over the hurdles that stopped me. It would be great to see the issues resolved. If that happens in the next few weeks then Blogger's interface will get a little bit of free publicity in a book on the subject. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 25 14:27:40 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 OAA21569 for ; Mon, 25 Oct 2004 14:27:39 -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 i9PIFPf9092462; Mon, 25 Oct 2004 11:15:25 -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 i9PIFP6Z092461; Mon, 25 Oct 2004 11:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PIFNZA092426 for ; Mon, 25 Oct 2004 11:15:24 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 25-Oct-2004 19:15:22 +0100 From: "Mark Birbeck" To: "'Danny Ayers'" Cc: Subject: RE: XML2004Hackathon Date: Mon, 25 Oct 2004 19:14:50 +0100 Message-ID: <00a601c4babe$88506820$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <1f2ed5cd04102510162fc84aa0@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9PIFPZA092456 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Danny, Yes, we too had many hair-pulling moments! In fairness to Blogger, the *really* big problem I would say is not returning XML from a SOAP GET, since without that feature you can't get the workflow on the client right. In other words is prevents you from building a 'correct' application. That's not, of course, to say that the other issues aren't important, but things like being open to a replay attack are hopefully just things that will get sorted soon, and since we've implemented our client to use nonces correctly, it will hopefully 'just work' when it is fixed. Since we have managed to get over many of the hurdles, anyone who is having problems building a Blogger client in whatever language they are using might find it useful to look at our XForms client [1]. Even if you don't install formsPlayer, and instead just look at our code, you'll probably find some useful stuff in there. Regards, Mark [1] Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ > -----Original Message----- > From: owner-atom-syntax@mail.imc.org > [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Danny Ayers > Sent: 25 October 2004 18:16 > To: Mark Birbeck > Cc: Greg Stein; atom-syntax@imc.org; Tim Bray > Subject: Re: XML2004Hackathon > > > > On the subject of blogger.com Atom, I also tried > unsuccessfully to get a SOAP client to work, as have others, > check this blog post (especially comments): > > http://dannyayers.com/archives/2004/10/02/it-just-works/ > > It sounds like Mark was able to get over the hurdles that > stopped me. It would be great to see the issues resolved. If > that happens in the next few weeks then Blogger's interface > will get a little bit of free publicity in a book on the subject. > > Cheers, > Danny. > > -- > > http://dannyayers.com > > > From owner-atom-syntax@mail.imc.org Mon Oct 25 14:48:44 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 OAA23016 for ; Mon, 25 Oct 2004 14:48: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 i9PIYlqP097075; Mon, 25 Oct 2004 11:34:47 -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 i9PIYlea097074; Mon, 25 Oct 2004 11:34:47 -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 i9PIYkws097058 for ; Mon, 25 Oct 2004 11:34:46 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CM9g1-0006i9-AI; Mon, 25 Oct 2004 18:34:41 +0000 Message-ID: <417D4740.4010002@franklinmint.fm> Date: Mon, 25 Oct 2004 14:34:40 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Birbeck CC: atom-syntax@imc.org Subject: Re: XML2004Hackathon References: <006c01c4baa2$b9ae9070$6701a8c0@W100> In-Reply-To: <006c01c4baa2$b9ae9070$6701a8c0@W100> 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 Mark Birbeck wrote: > > * PUT SOAP requests seem to incorrectly require that certain attributes are > *not* present. > I found that SOAP PUTS seemed to have PostURI POST request body constraints applied. Blogger wouldn't let me send and required . This assumes draft-gregorio-09 support. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 25 18:05:29 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 SAA24248 for ; Mon, 25 Oct 2004 18:05:29 -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 i9PLtPsi031111; Mon, 25 Oct 2004 14:55:25 -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 i9PLtPdp031110; Mon, 25 Oct 2004 14:55:25 -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 i9PLtPxe031103 for ; Mon, 25 Oct 2004 14:55:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CMCoH-0005gw-Q5; Mon, 25 Oct 2004 21:55:25 +0000 Message-ID: <417D764C.1090607@franklinmint.fm> Date: Mon, 25 Oct 2004 17:55:24 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Birbeck CC: atom-syntax@imc.org Subject: Re: XML2004Hackathon References: <000b01c4badc$5e2597f0$0e01a8c0@W100> In-Reply-To: <000b01c4badc$5e2597f0$0e01a8c0@W100> 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 Mark Birbeck wrote: > Robert, > > >>I found that SOAP PUTS seemed to have PostURI POST request body >>constraints applied. Blogger wouldn't let me send and >>required . This assumes draft-gregorio-09 support. > > > Good detective work! That does seem to explain most of them, although we > also found that atom:issued was not allowed, and that is actually required > by both EditURI/PUT and PostURI. > That's not my experience. MobileAtom J2ME[0] sends atom:issued and it works fine. However, your observation about the nesting divs was a new one on me, and I verified it in my implementation. I swear it didn't used to do that. Robert Sayre [0] http://www.franklinmint.fm/2004/09/27/mobile_atom.html From owner-atom-syntax@mail.imc.org Mon Oct 25 18:14: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 SAA27369 for ; Mon, 25 Oct 2004 18:14: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 i9PLnA7Z030562; Mon, 25 Oct 2004 14:49:10 -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 i9PLnAfg030561; Mon, 25 Oct 2004 14:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PLn7MW030541 for ; Mon, 25 Oct 2004 14:49:08 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [81.156.155.211] BY S009 with hMailServer ; 25-Oct-2004 22:48:41 +0100 From: "Mark Birbeck" To: "'Robert Sayre'" Cc: Subject: RE: XML2004Hackathon Date: Mon, 25 Oct 2004 22:48:24 +0100 Message-ID: <000b01c4badc$5e2597f0$0e01a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <417D4740.4010002@franklinmint.fm> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert, > I found that SOAP PUTS seemed to have PostURI POST request body > constraints applied. Blogger wouldn't let me send and > required . This assumes draft-gregorio-09 support. Good detective work! That does seem to explain most of them, although we also found that atom:issued was not allowed, and that is actually required by both EditURI/PUT and PostURI. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Mon Oct 25 18:18:43 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 SAA28452 for ; Mon, 25 Oct 2004 18:18:42 -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 i9PM4Xa0032315; Mon, 25 Oct 2004 15:04: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 i9PM4Xbl032314; Mon, 25 Oct 2004 15:04:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PM4Wgi032297 for ; Mon, 25 Oct 2004 15:04:32 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [81.156.155.211] BY S009 with hMailServer ; 25-Oct-2004 23:04:34 +0100 From: "Mark Birbeck" To: Cc: Subject: RE: XML2004Hackathon Date: Mon, 25 Oct 2004 23:04:21 +0100 Message-ID: <001401c4bade$98359150$0e01a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <417D764C.1090607@franklinmint.fm> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9PM4Wgi032309 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert, > > ... although > > we also found that atom:issued was not allowed, and that is > actually > > required by both EditURI/PUT and PostURI. > > > > That's not my experience. MobileAtom J2ME[0] sends atom:issued and it > works fine. Thanks for that -- we'll check it again. Perhaps we formatted the date wrong, or something. > However, your observation about the nesting divs > was a new > one on me, and I verified it in my implementation. I swear it didn't > used to do that. I couldn't say how long it's been there, because we only recently managed to get the authentication working, and so have only recently started drilling into the detail. > Robert Sayre > > [0] http://www.franklinmint.fm/2004/09/27/mobile_atom.html Looks very good, and a useful tutorial. Thanks for the reference. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Mon Oct 25 19:08:11 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 TAA10340 for ; Mon, 25 Oct 2004 19:08:10 -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 i9PN1aon037268; Mon, 25 Oct 2004 16:01:36 -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 i9PN1ajc037267; Mon, 25 Oct 2004 16:01:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PN1aCo037261 for ; Mon, 25 Oct 2004 16:01:36 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9PN1fui016031 for ; Mon, 25 Oct 2004 17:01:41 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6500DXCXASNH@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 25 Oct 2004 17:01:40 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6500C1LXARI5@mail.sun.net> for atom-syntax@imc.org; Mon, 25 Oct 2004 17:01:40 -0600 (MDT) Date: Mon, 25 Oct 2004 16:02:14 -0700 From: Tim Bray Subject: Link housekeeping: PaceFieldingLinks and maintenance To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT I just created PaceFieldingLinks to capture Roy's proposal: http://www.intertwingly.net/wiki/pie/PaceFieldingLinks I also noted that existing link-related Paces are not up-to-date with the format-03 draft. I think I'll ask Sam to consider closing any link-related Paces that haven't been updated relative to the current format draft when the time comes to discuss them again. -Tim From owner-atom-syntax@mail.imc.org Mon Oct 25 19:37: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 TAA16937 for ; Mon, 25 Oct 2004 19:37: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 i9PNVE9h039202; Mon, 25 Oct 2004 16:31:14 -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 i9PNVEKM039201; Mon, 25 Oct 2004 16:31:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PNVEmd039193 for ; Mon, 25 Oct 2004 16:31:14 -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 (rwcrmhc13) with SMTP id <2004102523311201500n3e2le>; Mon, 25 Oct 2004 23:31:12 +0000 Date: Mon, 25 Oct 2004 17:31:10 -0600 Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance 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: Message-Id: 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 Monday, October 25, 2004, at 05:02 PM, Tim Bray wrote: > I just created PaceFieldingLinks to capture Roy's proposal: > http://www.intertwingly.net/wiki/pie/PaceFieldingLinks > Given that people are virtually never going to want the same xml:base to apply to @rel and @href, I don't think xml:base should apply to @rel. The idea in the Pace is of course what we want, but xml:base doesn't seem like the right way to get there. Perhaps something like: 'If the value of "rel" is not an absolute URI, software MUST prepend "http://www.iana.org/assignments/TBD/" to it.' or 'If the value of "rel" is not an absolute URI, software MUST act as if xml:base were set to "http://www.iana.org/assignments/TBD/".'...except we'd need to be sure it was clear that that only applied to @rel, and not @href also. From owner-atom-syntax@mail.imc.org Mon Oct 25 19:47:04 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 TAA19066 for ; Mon, 25 Oct 2004 19:47: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 i9PNeUNa039733; Mon, 25 Oct 2004 16:40:30 -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 i9PNeU5a039732; Mon, 25 Oct 2004 16:40:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PNeTvf039716 for ; Mon, 25 Oct 2004 16:40:29 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by lois.corp.google.com (8.12.11/8.12.11) with ESMTP id i9PNdqoZ002482 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 25 Oct 2004 16:39:52 -0700 In-Reply-To: <006c01c4baa2$b9ae9070$6701a8c0@W100> References: <006c01c4baa2$b9ae9070$6701a8c0@W100> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A9CAED0-26DF-11D9-BF41-000A95B09B46@google.com> Content-Transfer-Encoding: 7bit Cc: atom syntax list From: steve jenson Subject: Re: XML2004Hackathon Date: Mon, 25 Oct 2004 16:39:51 -0700 To: "Mark Birbeck" X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 25, 2004, at 7:55 AM, Mark Birbeck wrote: > Greg, > >> Because Steve has no reason to go to the conference *other* >> than the Atom interop. If we're going to test Blogger with >> one other piece of software, then it is much more preferable >> for Steve to pick up the phone and talk to that person. >> >> As of right now, there are only three pieces of software listed. It is >> *very* hard to justify Steve's time and expense for what >> could otherwise be accomplished with an afternoon conference call. > > I sympathise with Google having to keep an eye on its expenses budget > ;) -- > and since I will not be heading for XML 2004 and the Hackathon, I > thought > I'd list here some of the issues with the Blogger.com Atom API. > (Though if > there is a way to remotely join the event on the day, we'll make every > effort to do so.) > > Background -- we have implemented an Atom client using declarative > mark-up, > namely XForms [1]. During the course of this we identified a number of > problems with Blogger's Atom API implementation, as follows: > > * GET SOAP requests don't return well-formed XML (link tags are > opened but > never closed). This is such a fundamental problem that I don't know > how > other people are managing to use your API, unless either (a) they > are > using SAX and so can be a bit more tolerant of errors, or (b) they > do > what we have to do and use the atom.xml document. Digging through the code, I see where this bug is, and a couple of unit tests will pin it down. > * Authentication doesn't seem to be implemented correctly, so a replay > attack > would be possible. We're going to be moving to Basic over HTTPS by the end of this year so I don't plan to fix this. If we were going to keep it long-term, it would definitely be fixed. > * atom:content wraps all text with html:div, including content that is > already > contained in a div, which means that if you do nothing about it you > get > an > ever growing number of blank lines as you edit and re-edit. I will fix. > I hope that helps, and it would be great to see these issues solved. Thank you for the feedback, it's been super helpful. I will get these issues taken care of. I apologize for the crappy state of our SOAP API. In general, I think this highlights the need for a strong community-supplied test suite. The only one I know of is bikini, which doesn't look very active. Does anybody know the status of this or any other public test suite that I could contribute to? -steve From owner-atom-syntax@mail.imc.org Mon Oct 25 19:53: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 TAA19913 for ; Mon, 25 Oct 2004 19:53: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 i9PNlCgZ040233; Mon, 25 Oct 2004 16:47: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 i9PNlCHT040232; Mon, 25 Oct 2004 16:47:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PNlBv0040226 for ; Mon, 25 Oct 2004 16:47:12 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v18so242365rnb for ; Mon, 25 Oct 2004 16:47:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=szfCREnVdrM5qJIaKDype2TQ+E7JkFWMlDYnGh1kOt7ivppHqlCAEJm1OndxNEwSVp/V/L4AmgNCg5w5FVBnte2kr5PQUkUt988C/vtYN1iOB7AUDOfv4vwDKeolMGPMgyIoUSVGnE6Lc7Z5aN/8RjoX5FOWRLS9qcmoL6m7Jjc= Received: by 10.38.8.2 with SMTP id 2mr1825332rnh; Mon, 25 Oct 2004 16:47:15 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Mon, 25 Oct 2004 16:47:15 -0700 (PDT) Message-ID: <1f2ed5cd041025164759a07063@mail.gmail.com> Date: Tue, 26 Oct 2004 01:47:15 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy's suggestion made sense at the time, but now I seem to be missing something: "This provides a basis for extensibility of the atom:link element which provides both the benefits of an IANA registry and those of a decentralized URI-based mechanism." In what respect does it provide the benefits of a decentralized URI-based mechanism, when *every* value has the same base? It will say it's not like other URIs, but that isn't a problem anyhow. The nearest problem is telling the difference between two rel values with the same (local) name. What's more the potential for reuse of relational terms defined in other vocabularies is lost. If we must have registration, why not simply allow registry of full URIs? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon Oct 25 20:01: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 UAA21023 for ; Mon, 25 Oct 2004 20:01: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 i9PNupwM040801; Mon, 25 Oct 2004 16:56:51 -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 i9PNup1K040800; Mon, 25 Oct 2004 16:56:51 -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 i9PNupP5040794 for ; Mon, 25 Oct 2004 16:56:51 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CMEho-0000lS-39; Mon, 25 Oct 2004 23:56:52 +0000 Message-ID: <417D92C4.4030504@franklinmint.fm> Date: Mon, 25 Oct 2004 19:56:52 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Tim Bray , Atom Syntax Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance References: <1f2ed5cd041025164759a07063@mail.gmail.com> In-Reply-To: <1f2ed5cd041025164759a07063@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > > If we must have registration, why not simply allow registry of full URIs? > I believe the original suggestion[0] was that the attribute value be a URI Reference, with Relative References using a base controlled by a registry. The proposal didn't touch on registration of full URIs. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg10681.html From owner-atom-syntax@mail.imc.org Mon Oct 25 20:07: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 UAA21924 for ; Mon, 25 Oct 2004 20:07: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 i9PNrDwl040536; Mon, 25 Oct 2004 16:53: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 i9PNrDHR040535; Mon, 25 Oct 2004 16:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PNrDKX040528 for ; Mon, 25 Oct 2004 16:53:13 -0700 (PDT) (envelope-from distobj@acm.org) Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1CMEgD-0002S4-00; Mon, 25 Oct 2004 19:55:13 -0400 Date: Mon, 25 Oct 2004 19:55:13 -0400 To: Danny Ayers Cc: Atom Syntax Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Message-ID: <20041025235513.GI30868@markbaker.ca> References: <1f2ed5cd041025164759a07063@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2ed5cd041025164759a07063@mail.gmail.com> User-Agent: Mutt/1.3.28i From: Mark Baker Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 26, 2004 at 01:47:15AM +0200, Danny Ayers wrote: > In what respect does it provide the benefits of a decentralized > URI-based mechanism, when *every* value has the same base? When the value is a URI, of course. Silly wabbit! Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca From owner-atom-syntax@mail.imc.org Mon Oct 25 20:12: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 UAA22758 for ; Mon, 25 Oct 2004 20:12: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 i9Q05OjF041663; Mon, 25 Oct 2004 17:05: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 i9Q05Ob4041662; Mon, 25 Oct 2004 17:05:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40826.mail.yahoo.com (web40826.mail.yahoo.com [66.218.92.73]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9Q05O98041643 for ; Mon, 25 Oct 2004 17:05:24 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041026000523.26445.qmail@web40826.mail.yahoo.com> Received: from [131.107.76.143] by web40826.mail.yahoo.com via HTTP; Mon, 25 Oct 2004 17:05:23 PDT Date: Mon, 25 Oct 2004 17:05:23 -0700 (PDT) From: Dare Obasanjo Subject: Re: XML2004Hackathon To: steve jenson , Mark Birbeck Cc: atom syntax list In-Reply-To: <2A9CAED0-26DF-11D9-BF41-000A95B09B46@google.com> 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: --- steve jenson wrote: > > We're going to be moving to Basic over HTTPS by the > end of this year so > I don't plan to fix this. If we were going to keep > it long-term, it > would definitely be fixed. Doesn't this run counter to Section 3.7 of the most recent draft of the Atom API spec at http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt which requires one of either HTTP Digest or CGI authentication (whatever the hell that is) ? So you plan to wilfully ignore the spec in this regard? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Mon Oct 25 20:21:09 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 UAA23656 for ; Mon, 25 Oct 2004 20:21: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 i9Q0EwCo042220; Mon, 25 Oct 2004 17:14:58 -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 i9Q0EwBn042219; Mon, 25 Oct 2004 17:14:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q0EvTA042210 for ; Mon, 25 Oct 2004 17:14:57 -0700 (PDT) (envelope-from stevej@google.com) Received: from [172.24.68.136] (chopper.corp.google.com [172.24.68.136]) (authenticated bits=0) by vegeta.corp.google.com (8.12.11/8.12.11) with ESMTP id i9Q0Er5Q016552 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 25 Oct 2004 17:14:53 -0700 In-Reply-To: <20041026000523.26445.qmail@web40826.mail.yahoo.com> References: <20041026000523.26445.qmail@web40826.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F196767-26E4-11D9-BF41-000A95B09B46@google.com> Content-Transfer-Encoding: 7bit Cc: atom syntax list From: steve jenson Subject: Re: XML2004Hackathon Date: Mon, 25 Oct 2004 17:14:53 -0700 To: Dare Obasanjo X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 25, 2004, at 5:05 PM, Dare Obasanjo wrote: > --- steve jenson wrote: >> >> We're going to be moving to Basic over HTTPS by the >> end of this year so >> I don't plan to fix this. If we were going to keep >> it long-term, it >> would definitely be fixed. > > Doesn't this run counter to Section 3.7 of the most > recent draft of the Atom API spec at > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt > which requires one of either HTTP Digest or CGI > authentication (whatever the hell that is) ? > > So you plan to wilfully ignore the spec in this > regard? I'm afraid we have no option for implementing Digest, just like many other providers. Steve From owner-atom-syntax@mail.imc.org Mon Oct 25 20:22:16 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 UAA23767 for ; Mon, 25 Oct 2004 20:22:15 -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 i9Q084PH041872; Mon, 25 Oct 2004 17:08:04 -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 i9Q084q9041871; Mon, 25 Oct 2004 17:08:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q083Jh041864 for ; Mon, 25 Oct 2004 17:08:04 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9Q089ui013277 for ; Mon, 25 Oct 2004 18:08:09 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I66000B40DKFJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 25 Oct 2004 18:08:09 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I66005C80DF9P@mail.sun.net> for atom-syntax@imc.org; Mon, 25 Oct 2004 18:08:08 -0600 (MDT) Date: Mon, 25 Oct 2004 17:08:39 -0700 From: Tim Bray Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance In-reply-to: <1f2ed5cd041025164759a07063@mail.gmail.com> To: Danny Ayers Cc: Atom Syntax Message-id: <305D819A-26E3-11D9-8B9A-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1f2ed5cd041025164759a07063@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 25, 2004, at 4:47 PM, Danny Ayers wrote: > In what respect does it provide the benefits of a decentralized > URI-based mechanism, when *every* value has the same base? No, it's a URI reference. By default the base is the IANA registry. You can put a full URI in there or reset the base with xml:base. -Tim From owner-atom-syntax@mail.imc.org Mon Oct 25 20:23: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 UAA23934 for ; Mon, 25 Oct 2004 20:23: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 i9Q0Itht042402; Mon, 25 Oct 2004 17:18: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 i9Q0Itud042401; Mon, 25 Oct 2004 17:18:55 -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 i9Q0ItSO042395 for ; Mon, 25 Oct 2004 17:18:55 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CMF3C-0005Ao-Uw; Tue, 26 Oct 2004 00:18:59 +0000 Message-ID: <417D97F0.4080404@franklinmint.fm> Date: Mon, 25 Oct 2004 20:18:56 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: steve jenson CC: Dare Obasanjo , atom syntax list Subject: Re: XML2004Hackathon References: <20041026000523.26445.qmail@web40826.mail.yahoo.com> <0F196767-26E4-11D9-BF41-000A95B09B46@google.com> In-Reply-To: <0F196767-26E4-11D9-BF41-000A95B09B46@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit steve jenson wrote: > > On Oct 25, 2004, at 5:05 PM, Dare Obasanjo wrote: > >> --- steve jenson wrote: >> >>> >>> We're going to be moving to Basic over HTTPS by the >>> end of this year so >>> I don't plan to fix this. If we were going to keep >>> it long-term, it >>> would definitely be fixed. >> >> >> Doesn't this run counter to Section 3.7 of the most >> recent draft of the Atom API spec at >> http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt >> which requires one of either HTTP Digest or CGI >> authentication (whatever the hell that is) ? >> >> So you plan to wilfully ignore the spec in this >> regard? > > > I'm afraid we have no option for implementing Digest, just > like many other providers. So far, the requirements in that section of the draft have gotten a rather cool reception. I now agree that it's kind of silly to require a certain authentication mechanism. What if someone only wants their service available through full Kerberos authentication? Seems silly to say such a service isn't compliant. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 25 20:41: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 UAA25338 for ; Mon, 25 Oct 2004 20:41:34 -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 i9Q0RYdu043465; Mon, 25 Oct 2004 17:27: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 i9Q0RYU3043464; Mon, 25 Oct 2004 17:27:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40829.mail.yahoo.com (web40829.mail.yahoo.com [66.218.92.76]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9Q0RXTo043454 for ; Mon, 25 Oct 2004 17:27:33 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041026002734.97220.qmail@web40829.mail.yahoo.com> Received: from [131.107.76.30] by web40829.mail.yahoo.com via HTTP; Mon, 25 Oct 2004 17:27:34 PDT Date: Mon, 25 Oct 2004 17:27:34 -0700 (PDT) From: Dare Obasanjo Subject: Re: XML2004Hackathon To: mint@franklinmint.fm, steve jenson Cc: atom syntax list In-Reply-To: <417D97F0.4080404@franklinmint.fm> 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: --- Robert Sayre wrote: > > > I'm afraid we have no option for implementing > Digest, just > > like many other providers. > > So far, the requirements in that section of the > draft have gotten a > rather cool reception. I now agree that it's kind of > silly to require a > certain authentication mechanism. What if someone > only wants their > service available through full Kerberos > authentication? Seems silly to > say such a service isn't compliant. There are two points here. The first is that the spec implies that if clients support CGI or Digest authentication they should be covered when it comes to authentication. However we have a major blogging tool vendor claiming that they plan to ignore that part of the spec which makes the spec not worth the much. More importantly, restricting what authentication mechanisms people can use is just plain silly. Perhaps we should take this to atom-protocol? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Mon Oct 25 20:58: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 UAA26374 for ; Mon, 25 Oct 2004 20:58:29 -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 i9Q0rUYr044906; Mon, 25 Oct 2004 17:53:30 -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 i9Q0rUrY044905; Mon, 25 Oct 2004 17:53:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from postal.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q0rTMU044862 for ; Mon, 25 Oct 2004 17:53:29 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 989A4D9 for ; Mon, 25 Oct 2004 17:53:28 -0700 (PDT) Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9Q0rRhc001763 for ; Mon, 25 Oct 2004 17:53:27 -0700 (PDT) Date: Mon, 25 Oct 2004 17:53:27 -0700 From: Walter Underwood To: atom syntax list Subject: Re: XML2004Hackathon Message-ID: <8B7B2944ACF48AB72A70F30C@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <20041026002734.97220.qmail@web40829.mail.yahoo.com> References: <20041026002734.97220.qmail@web40829.mail.yahoo.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Monday, October 25, 2004 5:27 PM -0700 Dare Obasanjo wrote: > > More importantly, restricting what authentication > mechanisms people can use is just plain silly. No, it is all about interoperability. If a server and a client implement incompatible set of auth mechanisms, they cannot talk. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Oct 25 20:59: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 UAA26438 for ; Mon, 25 Oct 2004 20:59: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 i9Q0j1Rv044417; Mon, 25 Oct 2004 17:45:01 -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 i9Q0j1Iv044416; Mon, 25 Oct 2004 17:45:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q0j1XB044406 for ; Mon, 25 Oct 2004 17:45:01 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 43so116653wri for ; Mon, 25 Oct 2004 17:45:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CIpIWINolQ50VfblzTagep80XP+z9FdsGqrbGnZq9AEsEY7+xl+luzci+BT8DIXf0iiiQknlmggyahoV9KoTBcPoB9kwbSWCKkOItOpefeVnZw8ufSHrV+7B+nO8Rcyx2B883m3mvDgxPdnjlxQTeIr2cwascWErI7gcC/CobZ8= Received: by 10.38.218.39 with SMTP id q39mr95439rng; Mon, 25 Oct 2004 17:45:01 -0700 (PDT) Received: by 10.38.151.74 with HTTP; Mon, 25 Oct 2004 17:45:01 -0700 (PDT) Message-ID: <3f1451f50410251745758650d8@mail.gmail.com> Date: Mon, 25 Oct 2004 20:45:01 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: steve jenson Subject: Re: XML2004Hackathon Cc: Dare Obasanjo , atom syntax list In-Reply-To: <0F196767-26E4-11D9-BF41-000A95B09B46@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041026000523.26445.qmail@web40826.mail.yahoo.com> <0F196767-26E4-11D9-BF41-000A95B09B46@google.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 25 Oct 2004 17:14:53 -0700, steve jenson wrote: > > On Oct 25, 2004, at 5:05 PM, Dare Obasanjo wrote: > > > --- steve jenson wrote: > >> > >> We're going to be moving to Basic over HTTPS by the > >> end of this year so > >> I don't plan to fix this. If we were going to keep > >> it long-term, it > >> would definitely be fixed. > > > > Doesn't this run counter to Section 3.7 of the most > > recent draft of the Atom API spec at > > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-02.txt > > which requires one of either HTTP Digest or CGI > > authentication (whatever the hell that is) ? > > > > So you plan to wilfully ignore the spec in this > > regard? > > I'm afraid we have no option for implementing Digest, just > like many other providers. That section shouldn't be so explicit. It should be reworded to encourage (via SHOULD) both RFC 2617 compatible authentication and also some sort of encryption, such as HTTPS. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Oct 25 21:11: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 VAA27387 for ; Mon, 25 Oct 2004 21:11: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 i9Q15UxA045918; Mon, 25 Oct 2004 18:05:30 -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 i9Q15UkS045917; Mon, 25 Oct 2004 18:05:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40810.mail.yahoo.com (web40810.mail.yahoo.com [66.218.78.187]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9Q15TGd045880 for ; Mon, 25 Oct 2004 18:05:29 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041026010526.57393.qmail@web40810.mail.yahoo.com> Received: from [131.107.71.225] by web40810.mail.yahoo.com via HTTP; Mon, 25 Oct 2004 18:05:26 PDT Date: Mon, 25 Oct 2004 18:05:26 -0700 (PDT) From: Dare Obasanjo Subject: Re: XML2004Hackathon To: Walter Underwood , atom syntax list In-Reply-To: <8B7B2944ACF48AB72A70F30C@adsl-64-166-133-243.dsl.snfc21.pacbell.net> 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: --- Walter Underwood wrote: > > > More importantly, restricting what authentication > > mechanisms people can use is just plain silly. > > No, it is all about interoperability. If a server > and a client > implement incompatible set of auth mechanisms, they > cannot talk. So? The spec does not prevent that from happening since I can create a client that doesn't support auth or only supports one kind of authentication. Preventing more sophisticated authentication mechanisms in capable clients the name of interoperability doesn't seem like a good idea in today's extremely malicious and hostile Web. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Mon Oct 25 22:00: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 WAA00453 for ; Mon, 25 Oct 2004 22:00:29 -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 i9Q1rULE058522; Mon, 25 Oct 2004 18:53:30 -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 i9Q1rUlp058521; Mon, 25 Oct 2004 18:53:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q1rUpl058468 for ; Mon, 25 Oct 2004 18:53:30 -0700 (PDT) (envelope-from ezra@sixapart.com) Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239]) by rongo.sixapart.com (Postfix) with ESMTP id E2E37480CA for ; Mon, 25 Oct 2004 18:49:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-syntax@imc.org From: Ezra Cooper Subject: Atom Authentication [was Re: XML2004Hackathon] Date: Mon, 25 Oct 2004 18:54:27 -0700 X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 25, 2004, at 5:30 PM, Robert Sayre wrote: > [see atom-syntax for the rest of this thread] > > Dare Obasanjo wrote: >> --- Robert Sayre wrote: >> However we have a major blogging tool >> vendor claiming that they plan to ignore that part of >> the spec which makes the spec not worth the much. More importantly, >> restricting what authentication >> mechanisms people can use is just plain silly. Agreed. I don't see any reason to limit what authentication methods people use, but in the interests of interoperability and user experience, is it valuable to put forth one or a small number of options that clients should support? I think it is. Not by limiting the options, but by promoting a small number of good choices. The spec could say, "Atom clients SHOULD support one or more of the following methods..." A server which couldn't support any of the given options might still be a legitimate Atom implementation, but it "SHOULD" support some kind of authentication. Clients, of course, end up having to support the spec'd ones as well as any popular alternatives (Kerberos, say). If we choose the promoted options carefully, then in practice most clients would be able to support them all, and most servers would be able to support at least one. Is there any reason to think that interop will be harder to achieve here than it is in SMTP auth? My vote for the list would include "HTTP Digest" and "HTTP Basic Over TLS." This covers servers that can't support TLS, as well as those that can't handle a hashed password. Are there any other constituencies we should be thinking about? Ezra From owner-atom-syntax@mail.imc.org Tue Oct 26 01:07: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 BAA12902 for ; Tue, 26 Oct 2004 01:07: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 i9Q4vIwA099645; Mon, 25 Oct 2004 21:57: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 i9Q4vID4099644; Mon, 25 Oct 2004 21:57:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q4vHaq099637 for ; Mon, 25 Oct 2004 21:57:18 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 800E24F29B; Tue, 26 Oct 2004 00:57:20 -0400 (EDT) Message-Id: <6.0.0.20.2.20041026132210.05d2a288@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 26 Oct 2004 13:25:35 +0900 To: Tim Bray , Atom Syntax From: Martin Duerst Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance In-Reply-To: References: Mime-Version: 1.0 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 At 08:02 04/10/26, Tim Bray wrote: > >I just created PaceFieldingLinks to capture Roy's proposal: http://www.intertwingly.net/wiki/pie/PaceFieldingLinks > >I also noted that existing link-related Paces are not up-to-date with the format-03 draft. I think I'll ask Sam to consider closing any link-related Paces that haven't been updated relative to the current format draft when the time comes to discuss them again. -Tim Some comments: - I agree with Antone Rundy that this should always use the IANA registry as the base. Making this dependent on xml:base makes this much less usable. The Pace should explicitly state that xml:base does not apply. - In "Link constructs MAY have a rel attribute, whose value MUST be a string.", the second part ("whose value MUST be a string") is completely superfluous. Any XML attribute value is a string. - "New assignments must be approved by the IESG.": The most frequent way registries that I know are updated is by having an expert reviewer. Bothering the IESG with this is way too much of a hurdle. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Oct 26 01:51:36 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 BAA15760 for ; Tue, 26 Oct 2004 01:51: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 i9Q5aWtt020079; Mon, 25 Oct 2004 22:36: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 i9Q5aWNH020078; Mon, 25 Oct 2004 22:36:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q5aUuo020042 for ; Mon, 25 Oct 2004 22:36:31 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 26 Oct 2004 15:36:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 26 Oct 2004 15:36:34 +1000 Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <6.0.0.20.2.20041026132210.05d2a288@localhost> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> I just created PaceFieldingLinks to capture Roy's proposal: > http://www.intertwingly.net/wiki/pie/PaceFieldingLinks the idea is good, but the pace needs language addressing canonicalisation of URIs because the URIs which get put into @rel are used for comparison purposes, not retrieval. The simplest thing that could possibly work would be language stating that comparison of @rel values is as a character by character string comparison performed after prefixing the IANA registry base, and case sensitive/insensitive(?). e. From owner-atom-syntax@mail.imc.org Tue Oct 26 04:00: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 EAA08147 for ; Tue, 26 Oct 2004 04:00: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 i9Q7mBFP088314; Tue, 26 Oct 2004 00:48:11 -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 i9Q7mB4b088313; Tue, 26 Oct 2004 00:48:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9Q7mA7m088256 for ; Tue, 26 Oct 2004 00:48:10 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao06.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041026074800.ZLMA24432.fed1rmmtao06.cox.net@[192.168.0.100]>; Tue, 26 Oct 2004 03:48:00 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5D01FA94-2723-11D9-8B64-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Tue, 26 Oct 2004 00:48:02 -0700 To: Eric Scheid X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 25, 2004, at 10:36 PM, Eric Scheid wrote: >>> I just created PaceFieldingLinks to capture Roy's proposal: >> http://www.intertwingly.net/wiki/pie/PaceFieldingLinks > > the idea is good, but the pace needs language addressing > canonicalisation of > URIs because the URIs which get put into @rel are used for comparison > purposes, not retrieval. The simplest thing that could possibly work > would > be language stating that comparison of @rel values is as a character by > character string comparison performed after prefixing the IANA registry > base, and case sensitive/insensitive(?). It doesn't need language on canonicalization. Just penalize the losers who don't bother to be consistent. A plain old case-sensitive string comparison is sufficient to do the job -- it isn't even necessary to convert the registered URI reference to absolute form first if the base URI is set in stone, since people who want to use the full IANA URI for the registered name should be discouraged from wasting bits. ....Roy From owner-atom-syntax@mail.imc.org Tue Oct 26 06:45: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 GAA21722 for ; Tue, 26 Oct 2004 06:45: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 i9QAWdGq057558; Tue, 26 Oct 2004 03:32:39 -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 i9QAWdQ5057557; Tue, 26 Oct 2004 03:32:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QAWdg1057521 for ; Tue, 26 Oct 2004 03:32:39 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so373749wri for ; Tue, 26 Oct 2004 03:32:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dY/DDTVgByi2yS7rSqc/s49Yh0+ezh80xWBlhy6DQgoeTgss7o2U+gJeUMRXjX/T23lSeRPMMbn3+NdVyd0M/fe+wq/jFVWFCpHhmykCmWyX+x7PyCboOi9EOEuB4/P/uB2xSc1LU6mYWRXHuZh3/KZQ1jIhlUSimRD7CYEtv8c= Received: by 10.38.149.79 with SMTP id w79mr251668rnd; Tue, 26 Oct 2004 03:32:35 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 26 Oct 2004 03:32:35 -0700 (PDT) Message-ID: <1f2ed5cd04102603322f97171a@mail.gmail.com> Date: Tue, 26 Oct 2004 12:32:35 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Cc: Atom Syntax In-Reply-To: <305D819A-26E3-11D9-8B9A-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041025164759a07063@mail.gmail.com> <305D819A-26E3-11D9-8B9A-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 25 Oct 2004 17:08:39 -0700, Tim Bray wrote: > On Oct 25, 2004, at 4:47 PM, Danny Ayers wrote: > > > In what respect does it provide the benefits of a decentralized > > URI-based mechanism, when *every* value has the same base? > > No, it's a URI reference. By default the base is the IANA registry. > You can put a full URI in there or reset the base with xml:base. -Tim Ok thanks, That's the form that made sense, only the wording of the Pace is a little misleading. I suggest a rewording of the abstract from: "Define the rel attribute's value as being a URI reference whose base is an IANA registry." to something like: "Define the rel attribute's value as being a URI reference whose base is an IANA registry unless otherwise specified." and the addition of examples, like Eric's text: [[ rel="foo" and rel="http://example.org/foo" would have different bases. The former would act as if it is "http://iana.org/assignments/TBD/"+"foo", while the latter, being an absolute URI, would be what it is. ]] Historical note - the same kind of defaulting was specified in PaceLinkRelMechanism... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 26 06:58: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 GAA22957 for ; Tue, 26 Oct 2004 06:58: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 i9QAoi8W063927; Tue, 26 Oct 2004 03:50: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 i9QAoipO063926; Tue, 26 Oct 2004 03:50:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QAohI5063878 for ; Tue, 26 Oct 2004 03:50:44 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so376337wri for ; Tue, 26 Oct 2004 03:50:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=lNFfz11NHatVCPOByIGpDyYLzQtGs/xBaGwCYP9j6hx+vezAPVnzuhfKemWXWGNcFlrj0A3dQyDfpNglDTdUNsSzG7CfDJxsGUw/MVYHF5QxukxDGOBrzVMgLTTdrBmtB8W8gZ5O3+vddWxamZKs9uFKGxsifY+e6UkAykM+zAg= Received: by 10.38.149.71 with SMTP id w71mr249512rnd; Tue, 26 Oct 2004 03:50:40 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Tue, 26 Oct 2004 03:50:40 -0700 (PDT) Message-ID: <1f2ed5cd04102603504f3f02f4@mail.gmail.com> Date: Tue, 26 Oct 2004 12:50:40 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Joe Gregorio Subject: Re: XML2004Hackathon Cc: steve jenson , Dare Obasanjo , atom syntax list In-Reply-To: <3f1451f50410251745758650d8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041026000523.26445.qmail@web40826.mail.yahoo.com> <0F196767-26E4-11D9-BF41-000A95B09B46@google.com> <3f1451f50410251745758650d8@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 25 Oct 2004 20:45:01 -0400, Joe Gregorio wrote: > That section shouldn't be so explicit. +1 SHOULD on Digest and/or HTTPS I thought this had been dealt with ages ago. Mandating a single mechanism (e.g. Bob's) is inappropriate in such a heterogeneous environment. It should to be acceptable to build a zero-authentication Atom system, use cases include Wikis and whistleblowers. But a typical Atom system ought to contain something sturdier than HTTP Basic. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Oct 26 11:27:29 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 LAA14232 for ; Tue, 26 Oct 2004 11:27:28 -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 i9QF6EUj097512; Tue, 26 Oct 2004 08:06:14 -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 i9QF6EN0097511; Tue, 26 Oct 2004 08:06:14 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QF6D8s097502 for ; Tue, 26 Oct 2004 08:06:14 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <6.0.0.20.2.20041026132210.05d2a288@localhost> References: <6.0.0.20.2.20041026132210.05d2a288@localhost> Date: Tue, 26 Oct 2004 08:06:15 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance 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 1:25 PM +0900 10/26/04, Martin Duerst wrote: >- "New assignments must be approved by the IESG.": The most frequent > way registries that I know are updated is by having an expert reviewer. > Bothering the IESG with this is way too much of a hurdle. It is the IESG who assigns expert reviewers and approves their actions. We should let the IESG decide how they want to handle this without us telling them. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Oct 26 11:56:12 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 LAA17904 for ; Tue, 26 Oct 2004 11:56:11 -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 i9QFi9NT000976; Tue, 26 Oct 2004 08:44:09 -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 i9QFi932000974; Tue, 26 Oct 2004 08:44:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9QFi6kS000966 for ; Tue, 26 Oct 2004 08:44:06 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 26-Oct-2004 14:16:53 +0100 From: "Mark Birbeck" To: "'Danny Ayers'" Cc: "'atom syntax list'" Subject: RE: XML2004Hackathon Date: Tue, 26 Oct 2004 14:16:38 +0100 Message-ID: <000001c4bb5e$0a1b55a0$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1f2ed5cd04102603504f3f02f4@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9QFi8kS000969 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Danny, That all seems reasonable, but there would therefore need to be a way to tell an Atom client which security mechanism to use for a particular system. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ > -----Original Message----- > From: owner-atom-syntax@mail.imc.org > [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Danny Ayers > Sent: 26 October 2004 11:51 > To: Joe Gregorio > Cc: steve jenson; Dare Obasanjo; atom syntax list > Subject: Re: XML2004Hackathon > > > > On Mon, 25 Oct 2004 20:45:01 -0400, Joe Gregorio > wrote: > > > That section shouldn't be so explicit. > > +1 > > SHOULD on Digest and/or HTTPS > > I thought this had been dealt with ages ago. Mandating a > single mechanism (e.g. Bob's) is inappropriate in such a > heterogeneous environment. It should to be acceptable to > build a zero-authentication Atom system, use cases include > Wikis and whistleblowers. But a typical Atom system ought to > contain something sturdier than HTTP Basic. > > Cheers, > Danny. > > -- > > http://dannyayers.com > > > From owner-atom-syntax@mail.imc.org Tue Oct 26 12:34:49 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 MAA20964 for ; Tue, 26 Oct 2004 12:34:48 -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 i9QGGLiQ003202; Tue, 26 Oct 2004 09:16: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 i9QGGLHt003201; Tue, 26 Oct 2004 09:16:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QGGKvZ003191 for ; Tue, 26 Oct 2004 09:16:20 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 67so226617wri for ; Tue, 26 Oct 2004 09:16:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kwFlfmLgT9j2ZDdw6TfRQsw0VWjXQ7C28NB0Rn3+of9g+lfJPBZgfu9k3k9jpqO9AX8FP0UJryHkKkBJnlpkAgVxVl0nsBne68BBMJPW2u8EAHywiJ450ig1wVjcC9KxBiFvrgHcQ/WL6WL+arM6jC7+0A8z0YXwACLJAR3bZ6o= Received: by 10.38.181.44 with SMTP id d44mr374104rnf; Tue, 26 Oct 2004 09:16:18 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Tue, 26 Oct 2004 09:16:18 -0700 (PDT) Message-ID: <3f1451f504102609164cb2546e@mail.gmail.com> Date: Tue, 26 Oct 2004 12:16:18 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Mark Birbeck Subject: Re: XML2004Hackathon Cc: Danny Ayers , atom syntax list In-Reply-To: <000001c4bb5e$0a1b55a0$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04102603504f3f02f4@mail.gmail.com> <000001c4bb5e$0a1b55a0$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 26 Oct 2004 14:16:38 +0100, Mark Birbeck wrote: > > Danny, > > That all seems reasonable, but there would therefore need to be a way to > tell an Atom client which security mechanism to use for a particular system. That's what a status code of 401 and the WWW-Authenticate: header are for. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue Oct 26 14:21: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 OAA01099 for ; Tue, 26 Oct 2004 14:21: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 i9QI1bQP013732; Tue, 26 Oct 2004 11:01:37 -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 i9QI1bGm013731; Tue, 26 Oct 2004 11:01:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9QI1amR013721 for ; Tue, 26 Oct 2004 11:01:37 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 21395 messnum 2041453 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 26 Oct 2004 18:01:34 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail03.svc.cra.dublin.eircom.net (qp 21395) with SMTP; 26 Oct 2004 18:01:34 -0000 Message-ID: <417E90FC.7070509@dehora.net> Date: Tue, 26 Oct 2004 19:01:32 +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: Link housekeeping: PaceFieldingLinks and maintenance References: 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 Tim Bray wrote: > > I just created PaceFieldingLinks to capture Roy's proposal: > http://www.intertwingly.net/wiki/pie/PaceFieldingLinks > > I also noted that existing link-related Paces are not up-to-date with > the format-03 draft. I think I'll ask Sam to consider closing any > link-related Paces that haven't been updated relative to the current > format draft when the time comes to discuss them again. -Tim [[[ The value of "rel" MUST be a URI Reference [RFC2396bis, section 4.1]. For the atom:link element, if the xml:base attribute is not provided, software MUST act as though it were present with a value of "http://www.iana.org/assignments/TBD/", which identifies the IANA Registry of Atom Link Relations. ]]] Why aren't absolute URIs specified here? cheers Bill From owner-atom-syntax@mail.imc.org Tue Oct 26 14:57:47 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 OAA03275 for ; Tue, 26 Oct 2004 14:57:47 -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 i9QIjFx3017902; Tue, 26 Oct 2004 11:45: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 i9QIjFwI017900; Tue, 26 Oct 2004 11:45:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QIjDbs017894 for ; Tue, 26 Oct 2004 11:45:14 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9QIjHui005665 for ; Tue, 26 Oct 2004 12:45:17 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6700FCOG3HI4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 26 Oct 2004 12:45:17 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6700G8IG3GU3@mail.sun.net> for atom-syntax@imc.org; Tue, 26 Oct 2004 12:45:16 -0600 (MDT) Date: Tue, 26 Oct 2004 11:45:54 -0700 From: Tim Bray Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance In-reply-to: <417E90FC.7070509@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom Syntax Message-id: <4436F320-277F-11D9-94B7-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <417E90FC.7070509@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9QIjEbs017895 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Oct 26, 2004, at 11:01 AM, Bill de hÓra wrote: > The value of "rel" MUST be a URI Reference [RFC2396bis, section 4.1]. > For > the atom:link element, if the xml:base attribute is not provided, > software > MUST act as though it were present with a value of > "http://www.iana.org/assignments/TBD/", which identifies the IANA > Registry > of Atom Link Relations. > ]]] > > Why aren't absolute URIs specified here? So for things that are registered, like (initially) "alternate" and "related", you can just say and it all works. Unregistered things can be used, but you have to provide the whole URI -T From owner-atom-syntax@mail.imc.org Tue Oct 26 22:44:16 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 WAA23077 for ; Tue, 26 Oct 2004 22:44:16 -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 i9R2JDok007194; Tue, 26 Oct 2004 19:19: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 i9R2JDEx007193; Tue, 26 Oct 2004 19:19:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2JC8q007144; Tue, 26 Oct 2004 19:19:13 -0700 (PDT) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id C074D4F02D; Tue, 26 Oct 2004 22:19:12 -0400 (EDT) Message-Id: <6.0.0.20.2.20041027083222.08c0c8b8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 27 Oct 2004 08:38:07 +0900 To: Paul Hoffman / IMC , Atom WG From: Martin Duerst Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance In-Reply-To: References: <6.0.0.20.2.20041026132210.05d2a288@localhost> Mime-Version: 1.0 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 Hello Paul, At 00:06 04/10/27, Paul Hoffman / IMC wrote: > >At 1:25 PM +0900 10/26/04, Martin Duerst wrote: >>- "New assignments must be approved by the IESG.": The most frequent >> way registries that I know are updated is by having an expert reviewer. >> Bothering the IESG with this is way too much of a hurdle. > >It is the IESG who assigns expert reviewers and approves their actions. We should let the IESG decide how they want to handle this without us telling them. It turns out that there seem to be two different models of (expert) reviewers. The one I refered to is where the RFC defines that there is a reviewer that has to give his/her okay before things get registered with IANA. This is the case for charsets (you should know, because you are the reviewer) and language tags (see http://www.ietf.org/rfc/rfc3066.txt, Section 3), and media types in general (vnd,...). In these cases, the IESG doesn't get involved. The other model, the one you are referring to, is that the IESG assigns reviewers as part of their decision process. In that case, it's of course up to the IESG to handle things the way they want. However, what I was proposing is that we use the model used currently for charsets, language tags,..., which is considerably more lightweight and in my view more appropriate for the kind of registration we are dealing with. Regards, Martin. From owner-atom-syntax@mail.imc.org Wed Oct 27 00:06: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 AAA00012 for ; Wed, 27 Oct 2004 00:06: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 i9R3w19G027586; Tue, 26 Oct 2004 20:58:01 -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 i9R3w1MJ027585; Tue, 26 Oct 2004 20:58:01 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R3vrvA027573; Tue, 26 Oct 2004 20:57:58 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <6.0.0.20.2.20041027083222.08c0c8b8@localhost> References: <6.0.0.20.2.20041026132210.05d2a288@localhost> <6.0.0.20.2.20041027083222.08c0c8b8@localhost> Date: Tue, 26 Oct 2004 20:45:39 -0700 To: Martin Duerst , Atom WG From: Paul Hoffman / IMC Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance 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 8:38 AM +0900 10/27/04, Martin Duerst wrote: >Hello Paul, > >At 00:06 04/10/27, Paul Hoffman / IMC wrote: >> >>At 1:25 PM +0900 10/26/04, Martin Duerst wrote: >>>- "New assignments must be approved by the IESG.": The most frequent >>> way registries that I know are updated is by having an expert reviewer. >>> Bothering the IESG with this is way too much of a hurdle. >> >>It is the IESG who assigns expert reviewers and approves their >>actions. We should let the IESG decide how they want to handle this >>without us telling them. > >It turns out that there seem to be two different models of (expert) >reviewers. > >The one I refered to is where the RFC defines that there is a reviewer >that has to give his/her okay before things get registered with IANA. >This is the case for charsets (you should know, because you are the >reviewer) and language tags (see http://www.ietf.org/rfc/rfc3066.txt, >Section 3), and media types in general (vnd,...). In these cases, >the IESG doesn't get involved. > >The other model, the one you are referring to, is that the IESG >assigns reviewers as part of their decision process. In that case, >it's of course up to the IESG to handle things the way they want. > >However, what I was proposing is that we use the model used currently >for charsets, language tags,..., which is considerably more lightweight >and in my view more appropriate for the kind of registration we are >dealing with. In practice, the two models are identical. The IESG person responsible for the experts in both cases usually lets the experts do what they want with little supervision. Either is fine for what we need. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Oct 27 06:09:04 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 GAA22016 for ; Wed, 27 Oct 2004 06:09: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 i9R9t6CZ089384; Wed, 27 Oct 2004 02:55: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 i9R9t6HR089383; Wed, 27 Oct 2004 02:55:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9swpI089307 for ; Wed, 27 Oct 2004 02:54:58 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 74340 invoked by uid 17064); 27 Oct 2004 09:54:59 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.1.123]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Oct 2004 09:54:59 -0000 In-Reply-To: <417EBC1B.5050408@volus.net> References: <417EBC1B.5050408@volus.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <40013092-27FE-11D9-8917-000A95D9FA7A@bblfish.net> Cc: Atom Syntax , bloged From: Henry Story Subject: Re: licence for Ontologies Date: Wed, 27 Oct 2004 11:54:53 +0200 To: www-rdf-interest@w3.org, rdfweb-dev@vapours.rdfweb.org X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9R9sxpI089310 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Note: I have CCed a couple of other lists, especially the www-rdf-interest list as I think this problem is more general than any particular ontology, be it FOAF or Atom-OWL. The original question was asked here: There I suggested that ontologies should perhaps have a license that is more restrictive than the BSD license, in that they should allow free copying, but only very limited changes, nevertheless allow isomorphic ontologies to be developed (just change all the URI's) these being completely free to use any of the language in the original. ------------------------------------------- Thanks for your two responses, Ron and Peter. The most established license for our Atom-OWL code/ontology would be the BSD license with attributions to the creator, since it is over 30 years old. The BSD licence seems equivalent in spirit to the creative commons attribution and share-alike license, the FOAF group is using. One could even dual license it, I suppose. And initially at least, I am happy with both. I raised the question because I was not completely clear whether an ontology is code, text, or an interface specification/protocol, as suggested by Peter Saint-André. It also seems established practice with Ontologies to change all the URLs in the document for any substantial version change. Since the FOAF group itself does this when it moves to a new version, should not everyone else who wants to alter and improve on the ontology follow suite? [1] If there were a simple way to specify how to transform one ontology to a successor version this would not cause any problems. (perhaps this is being worked on) The two examples mentions by Ron Alford, >> Alternate copy of Annotea's http ontology to correct RDF/XML syntax >> errors. >> Alternate copies of foaf so that they made at least marginal sense >> when looking at them with an OWL parser. don't so much seem to be changes to the ontology as corrections to it. If one could allow corrections, translations into other RDF serializations, translations of the comments, that would be what ontology creators really would be looking for. But what does not seem quite right is taking an ontology, and redefining the terms to mean something completely different, or making slight changes to the relations between the terms, yet still leaving one the impression that one is speaking about the same thing, especially as it seems so easy to make the difference obvious by changing the URIs that compose the ontology. I suppose the question is how does this differ from a library written in C, lisp, or other such languages? My suggestion here would be that none of these language define their variables or functions as URIs ie *Universal* resource identifiers. The code sometimes calls functions in files that make reference to standards they implement (which in some sense makes the standards similar to URIs). When they don't make reference to such standards there is no universal statements made, and so changing or adapting a function to do something else in no way breaks any expectations. Changing an ontology in the way that concerns me and publishing it does on the other hand create a confusion. I will be happy to go with the BSD licence for the moment. But perhaps there is longer term a question here that needs looking at. Henry Story [1] I do this myself with the two Atom-OWL versions I proposed: - - On 26 Oct 2004, at 23:05, Ron Alford wrote on rdfweb-dev@vapours.rdfweb.org: > Henry Story wrote: >> you can copy this ontology as much as you wish, but cannot change >> the ontology it represents without agreement from the ontology >> copyright holder. You can on the other hand create an isomorphic >> ontology to this one, (change all the uris to different ones you >> own), and you can make any changes you wish to that one. > > As someone who continually finds himself having to make alternate > versions of ontologies, I would find that ontology exceptionally hard > to stomach. >> >> Here are some recent examples: >> Alternate copy of Annotea's http ontology to correct RDF/XML syntax >> errors. >> Alternate copies of foaf so that they made at least marginal sense >> when looking at them with an OWL parser. > > What are you afraid of with people making changes to the ontology? > That people might adopt an alternate view of your terms? > The semantic web seems /expressly/ designed to allow this. Perhaps this is indeed something I have not yet quite understood. > > > -Ron > On 27 Oct 2004, Peter Saint-André wrote, on rdfweb-dev@vapours.rdfweb.org > > Why are you looking for copyrights? Most protocols are free as the air > and anyone can implement them without restriction (protocols are not > code or writing -- I'm not sure how one would categorize an ontology, > but it seems more similar to a protocol than to code or writing). Also, > given the trends in U.S. copyright policy, recognize that anything you > copyright now will not go into the public domain until sometime in the > next century, if ever. > > Peter From owner-atom-syntax@mail.imc.org Wed Oct 27 07:25:38 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 HAA25950 for ; Wed, 27 Oct 2004 07:25:37 -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 i9RAIW3M000625; Wed, 27 Oct 2004 03:18: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 i9RAIWE3000624; Wed, 27 Oct 2004 03:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RAIVSl000522 for ; Wed, 27 Oct 2004 03:18:31 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 27-Oct-2004 11:18:18 +0100 From: "Mark Birbeck" To: "'Joe Gregorio'" Cc: "'atom syntax list'" Subject: Speifying mechanisms [was RE: XML2004Hackathon] Date: Wed, 27 Oct 2004 11:18:06 +0100 Message-ID: <009301c4bc0e$433f9160$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <3f1451f504102609164cb2546e@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RAIWSl000617 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Joe, > > That all seems reasonable, but there would therefore need > to be a way > > to tell an Atom client which security mechanism to use for a > > particular system. > > That's what a status code of 401 and the > WWW-Authenticate: header are for. Yes, but that's incredibly long-winded ... you have to fail before you know how to succeed. And also, if you have an Atom feed that contains references to entries that are on a number of different servers, you have to fail again for each server. In fact you may need to fail for each operation, because if we give one URL for new entries and another for edits, we might choose to use different security mechanisms for each. (Note also that WWW-Authenticate is protocol dependent, which -- so far -- much of Atom is not.) It seems to me that since the Atom architecture is very much about being able to find interact points 'dynamically', then all we would need to see is some information that tells us what security technique to use when accessing a particular URL. We can then avoid the trial and error approach, have a different security mechanism for each URL if we wanted to, and not fix things to any particular protocol. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Wed Oct 27 08:50: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 IAA00595 for ; Wed, 27 Oct 2004 08:50:37 -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 i9RCdrsQ051239; Wed, 27 Oct 2004 05:39: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 i9RCdrUU051238; Wed, 27 Oct 2004 05:39:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RCdp4w051194 for ; Wed, 27 Oct 2004 05:39:51 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so711121wri for ; Wed, 27 Oct 2004 05:39:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Y06DEfFsJijptaows8jCU5NKalgy66bOC34JcY4uvXLwMNHPyUZQsHThJcDuqk7S9Pbxgni6MpQejKOlVRPpLvFECtPf1vp8hYPhPW/KJNKuGNFRYt1X3MuuFhE3+Zbqo88Q7VGDfPOxX+EsWvCFJ4UC5j2jctoqt6UamxUg5sY= Received: by 10.38.13.79 with SMTP id 79mr799158rnm; Wed, 27 Oct 2004 05:39:43 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Wed, 27 Oct 2004 05:39:43 -0700 (PDT) Message-ID: <3f1451f504102705397a28e235@mail.gmail.com> Date: Wed, 27 Oct 2004 08:39:43 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Mark Birbeck Subject: Re: Speifying mechanisms [was RE: XML2004Hackathon] Cc: atom syntax list In-Reply-To: <009301c4bc0e$433f9160$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504102609164cb2546e@mail.gmail.com> <009301c4bc0e$433f9160$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 27 Oct 2004 11:18:06 +0100, Mark Birbeck wrote: > Yes, but that's incredibly long-winded ... you have to fail before you know > how to succeed. And also, if you have an Atom feed that contains references > to entries that are on a number of different servers, you have to fail again > for each server. In fact you may need to fail for each operation, because if > we give one URL for new entries and another for edits, we might choose to > use different security mechanisms for each. > > (Note also that WWW-Authenticate is protocol dependent, which -- so far -- > much of Atom is not.) > > It seems to me that since the Atom architecture is very much about being > able to find interact points 'dynamically', then all we would need to see is > some information that tells us what security technique to use when accessing > a particular URL. We can then avoid the trial and error approach, have a > different security mechanism for each URL if we wanted to, and not fix > things to any particular protocol. So... to avoid fixing things to a particular protocol we should try to fix things to a specific authentication mechanism? -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Oct 27 09:23:16 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 JAA02804 for ; Wed, 27 Oct 2004 09:23:16 -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 i9RD9ZFL057647; Wed, 27 Oct 2004 06:09:35 -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 i9RD9Zm6057645; Wed, 27 Oct 2004 06:09:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RD9Yi9057625 for ; Wed, 27 Oct 2004 06:09:35 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1CMnYW-0000PW-00; Wed, 27 Oct 2004 14:09:36 +0100 Date: Wed, 27 Oct 2004 14:09:36 +0100 From: James Aylett To: atom syntax list Subject: Re: Speifying mechanisms [was RE: XML2004Hackathon] Message-ID: <20041027130936.GO28499@tartarus.org> Mail-Followup-To: James Aylett , atom syntax list References: <3f1451f504102609164cb2546e@mail.gmail.com> <009301c4bc0e$433f9160$6701a8c0@W100> <3f1451f504102705397a28e235@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f504102705397a28e235@mail.gmail.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 27, 2004 at 08:39:43AM -0400, Joe Gregorio wrote: > > (Note also that WWW-Authenticate is protocol dependent, which -- so far -- > > much of Atom is not.) > > So... to avoid fixing things to a particular protocol we should > try to fix things to a specific authentication mechanism? I don't understand why this is Atom's problem at all. When Atom is working over HTTP and needs authentication, it uses HTTP authentication. If someone wants to transfer Atom over BEEP, say, then an appropriate authentication can be used there. On Wed, 27 Oct 2004 11:18:06 +0100, Mark Birbeck wrote: > That's incredibly long-winded ... you have to fail before you know > how to succeed. But only the first time; thereafter you can remember what to do next time. And the only place we can guarantee knows which mechanism to use is the endpoint that handles it. Anything that points to that endpoint could hint about mechanisms all it likes and still be incorrect. > In fact you may need to fail for each operation, because if we give > one URL for new entries and another for edits, we might choose to > use different security mechanisms for each. The producer might, but it's not that likely. And if they really wanted that, it was for a reason. Is a single 401 round-trip during first connection that costly? And even if it is, how do we make the hinting mechanism sufficiently flexible that it will work for non-HTTP transports? James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Wed Oct 27 09:26:40 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 JAA03109 for ; Wed, 27 Oct 2004 09:26:39 -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 i9RD9rGX057679; Wed, 27 Oct 2004 06:09:54 -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 i9RD9rnH057678; Wed, 27 Oct 2004 06:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RD9r0M057672 for ; Wed, 27 Oct 2004 06:09:53 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 46643 invoked by uid 17064); 27 Oct 2004 13:09:55 -0000 Received: from unknown (HELO [192.168.0.16]) ([83.112.14.141]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Oct 2004 13:09:55 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <40013092-27FE-11D9-8917-000A95D9FA7A@bblfish.net> References: <417EBC1B.5050408@volus.net> <40013092-27FE-11D9-8917-000A95D9FA7A@bblfish.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7BB812A6-2819-11D9-8917-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: licence for Ontologies Date: Wed, 27 Oct 2004 15:09:49 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry to atom-syntax readers. I mistakenly sent this on to this list, when I meant to send it on to the atom-owl group. Henry On 27 Oct 2004, at 11:54, Henry Story wrote: > > Note: I have CCed a couple of other lists, especially the > www-rdf-interest list as I think this problem is more general than any > particular ontology, be it FOAF or Atom-OWL. > The original question was asked here: > > > There I suggested that ontologies should perhaps have a license that > is more restrictive than the BSD license, in that they should allow > free copying, but only very limited changes, nevertheless allow > isomorphic ontologies to be developed (just change all the URI's) > these being completely free to use any of the language in the > original. > ------------------------------------------- > > [snip] From owner-atom-syntax@mail.imc.org Wed Oct 27 10:02: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 KAA04927 for ; Wed, 27 Oct 2004 10:02:10 -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 i9RDnfn3065352; Wed, 27 Oct 2004 06:49: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 i9RDnf3R065350; Wed, 27 Oct 2004 06:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RDne2u065291 for ; Wed, 27 Oct 2004 06:49:40 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 27-Oct-2004 14:49:29 +0100 From: "Mark Birbeck" To: "'Joe Gregorio'" Cc: "'atom syntax list'" Subject: RE: Speifying mechanisms Date: Wed, 27 Oct 2004 14:49:16 +0100 Message-ID: <00bf01c4bc2b$c31d27e0$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <3f1451f504102705397a28e235@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RDnf2u065343 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Joe, > So... to avoid fixing things to a particular protocol we > should try to fix things to a specific authentication mechanism? No ... And I'm trying to see how you could read that into what I said. I apologise if I didn't explain things very clearly. I can ask a server for a list of entries, and the server will give me both the list, and a set of URLs with which I can interact with those entries in the list. My suggestion is that we really need to have some additional information from the server to tell us what security information is required when we interact with those URLs. Ideally we would have one piece of metadata for each URL, so that not only can some 'blog service' have its security mechanism set, but each entry could also be accessed with a different mechanism. So I am saying the opposite of what you inferred. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Wed Oct 27 10:56:57 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 KAA11264 for ; Wed, 27 Oct 2004 10:56:56 -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 i9REiFCB076220; Wed, 27 Oct 2004 07:44: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 i9REiFsG076219; Wed, 27 Oct 2004 07:44:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9REiEWN076207 for ; Wed, 27 Oct 2004 07:44:14 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so745665wri for ; Wed, 27 Oct 2004 07:44:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Mx/A8IS15HMEq1mKsbrT1TM2Ov3H5PuG9sa1IwMuRd26KxhA6EbYrw9dFjCHvn8dHqnGMvNDnHuuXhdSp3AVDKP5wnmt6+/ZIn0prEdvBUM/Oxg8XmMZbcf/WztDexXjVTpGXTXPqfKDb001IyLtU6mnOzJM+4GmC32e5c2BtqI= Received: by 10.38.13.79 with SMTP id 79mr850893rnm; Wed, 27 Oct 2004 07:44:11 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Wed, 27 Oct 2004 07:44:11 -0700 (PDT) Message-ID: <3f1451f5041027074453a38d66@mail.gmail.com> Date: Wed, 27 Oct 2004 10:44:11 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Mark Birbeck Subject: Re: Speifying mechanisms Cc: atom syntax list In-Reply-To: <00bf01c4bc2b$c31d27e0$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f504102705397a28e235@mail.gmail.com> <00bf01c4bc2b$c31d27e0$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 27 Oct 2004 14:49:16 +0100, Mark Birbeck wrote: > Joe, > > > So... to avoid fixing things to a particular protocol we > > should try to fix things to a specific authentication mechanism? > > No ... And I'm trying to see how you could read that into what I said. I > apologise if I didn't explain things very clearly. > > I can ask a server for a list of entries, and the server will give me both > the list, and a set of URLs with which I can interact with those entries in > the list. Are you assuming here that accessing the FeedURI does not require authentication? -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Oct 27 11:01:23 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 LAA11692 for ; Wed, 27 Oct 2004 11:01:23 -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 i9REq7qB078217; Wed, 27 Oct 2004 07:52:07 -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 i9REq73q078216; Wed, 27 Oct 2004 07:52:07 -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 i9REq6QY078199 for ; Wed, 27 Oct 2004 07:52:06 -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 1CMp9V-0005cB-Dz; Wed, 27 Oct 2004 14:51:53 +0000 Message-ID: <417FB606.6090808@franklinmint.fm> Date: Wed, 27 Oct 2004 10:51:50 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Birbeck CC: "'Joe Gregorio'" , "'atom syntax list'" Subject: Re: Specifying mechanisms References: <00bf01c4bc2b$c31d27e0$6701a8c0@W100> In-Reply-To: <00bf01c4bc2b$c31d27e0$6701a8c0@W100> 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 Mark Birbeck wrote: > > I can ask a server for a list of entries, and the server will give me both > the list, and a set of URLs with which I can interact with those entries in > the list. My suggestion is that we really need to have some additional > information from the server to tell us what security information is required > when we interact with those URLs. Ideally we would have one piece of > metadata for each URL, so that not only can some 'blog service' have its > security mechanism set, but each entry could also be accessed with a > different mechanism. I disagree that we "really need" it. The requirement that each entry be accessible with a different authentication mechanism, yet remain under one user's control seems outlandish to me. Wouldn't most people just pick a single scheme that allowed flexible definitions of protection spaces, such as HTTP Digest? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Oct 27 11:10: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 LAA12783 for ; Wed, 27 Oct 2004 11:10:34 -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 i9REnWLt077563; Wed, 27 Oct 2004 07:49: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 i9REnWOW077562; Wed, 27 Oct 2004 07:49:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9REnV2C077554 for ; Wed, 27 Oct 2004 07:49:31 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 27-Oct-2004 15:49:31 +0100 From: "Mark Birbeck" To: "'Joe Gregorio'" Cc: "'atom syntax list'" Subject: RE: Speifying mechanisms Date: Wed, 27 Oct 2004 15:49:18 +0100 Message-ID: <00d701c4bc34$25c1b6b0$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <3f1451f5041027074453a38d66@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe, > Are you assuming here that accessing the FeedURI does > not require authentication? No ... but I was assuming that the whole thing was bootstrapped via the atom.xml-type file that Blogger.com and others have (which is obtained with a simple GET). Is that incorrect? Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Wed Oct 27 11:30:04 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 LAA15531 for ; Wed, 27 Oct 2004 11:30: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 i9RFGIBf083977; Wed, 27 Oct 2004 08:16: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 i9RFGIok083976; Wed, 27 Oct 2004 08:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RFGHS4083944 for ; Wed, 27 Oct 2004 08:16:18 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so756679wri for ; Wed, 27 Oct 2004 08:16:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mNciN6xWfOGip4QlioXzbSnZJU71PP72xUbIdXTHc4Ppc05FrEnZxkZOiMymyGXk9k4lQRGohNEBceouf40pFVK2MndggJEXLeX+WS2fn6bTFVg8SkOFu3NQ6OHoiPeUixb1qBukpIKHWfHShZCiFz3r41o6AnH8QvEyf0dTpYI= Received: by 10.38.76.16 with SMTP id y16mr860513rna; Wed, 27 Oct 2004 08:16:15 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Wed, 27 Oct 2004 08:16:15 -0700 (PDT) Message-ID: <3f1451f50410270816595558c5@mail.gmail.com> Date: Wed, 27 Oct 2004 11:16:15 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Mark Birbeck Subject: Re: Speifying mechanisms Cc: atom syntax list In-Reply-To: <00d701c4bc34$25c1b6b0$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f5041027074453a38d66@mail.gmail.com> <00d701c4bc34$25c1b6b0$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 27 Oct 2004 15:49:18 +0100, Mark Birbeck wrote: > Joe, > > > Are you assuming here that accessing the FeedURI does > > not require authentication? > > No ... but I was assuming that the whole thing was bootstrapped via the > atom.xml-type file that Blogger.com and others have (which is obtained with > a simple GET). Is that incorrect? Ah, ok, that *is* different from the FeedURI. In the case of blogger that file is only a GET, but a GET that requires authorization. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Oct 27 11:48:22 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 LAA17225 for ; Wed, 27 Oct 2004 11:48: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 i9RFeZNv090281; Wed, 27 Oct 2004 08:40:35 -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 i9RFeZZu090280; Wed, 27 Oct 2004 08:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RFeXVn090274 for ; Wed, 27 Oct 2004 08:40:34 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 27-Oct-2004 16:40:33 +0100 From: "Mark Birbeck" To: "'Joe Gregorio'" Cc: "'atom syntax list'" Subject: RE: Speifying mechanisms Date: Wed, 27 Oct 2004 16:40:20 +0100 Message-ID: <00e001c4bc3b$47269620$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <3f1451f50410270816595558c5@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RFeYVn090275 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Joe, > > No ... but I was assuming that the whole thing was bootstrapped via > > the atom.xml-type file that Blogger.com and others have (which is > > obtained with a simple GET). Is that incorrect? > > Ah, ok, that *is* different from the FeedURI. In the > case of blogger that file is only a GET, but a GET that > requires authorization. I understand. However, just to clarify what we're talking about here, I'm suggesting that the following list of entries might be both possible and desirable: . . . . . . . . . . . . As you can see here, the first entry comes from Blogger.com, and the second from a Wiki maintained using Atom. Each could have different authentication mechanisms, and until I try to save my changes -- and get a 401 -- I can't find out what they are. Going further, I don't see why I couldn't also have something like this: . . . Here the challenge/response mechanism might be separated by hours or days. Anyway, I think you can see what I'm getting at. As to how I 'get' a document that looks like this; it might have come from my own local machine, as I add a link to every document that I ever wrote, or my blogging client software may do the same, or it might even be from an online service, provided by The-next-big-company-after-Google which allows me to keep a list of all my blogs and anything I've ever written. But all my point was, that the very flexibility of the Atom architecture already means that you could be interacting with many different servers. I hope that explains where I am coming from. Best regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Wed Oct 27 13:48:44 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 NAA26752 for ; Wed, 27 Oct 2004 13:48: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 i9RH6CcR010751; Wed, 27 Oct 2004 10:06: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 i9RH6CdA010750; Wed, 27 Oct 2004 10:06:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RH6Afa010710 for ; Wed, 27 Oct 2004 10:06:11 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 67so403357wri for ; Wed, 27 Oct 2004 10:06:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZndslUf4/Bg8vteOmhrotGa5nitfl+QKLCkUFFt1DAmcCKosXJtQYULakiRA7sLvOPDLDqrBYbMKugnoQx7v2ok05bT2ogUZeBndvGoWl0sGTjIX2pRaZt/MTuTUB6WdZjMVV5qntgrvcARNTgNEL6XNwKxWrhHUpD80Fi4QPVo= Received: by 10.38.181.44 with SMTP id d44mr906411rnf; Wed, 27 Oct 2004 10:06:08 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Wed, 27 Oct 2004 10:06:08 -0700 (PDT) Message-ID: <3f1451f50410271006145ca8bd@mail.gmail.com> Date: Wed, 27 Oct 2004 13:06:08 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Mark Birbeck Subject: Re: Speifying mechanisms Cc: atom syntax list In-Reply-To: <00e001c4bc3b$47269620$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3f1451f50410270816595558c5@mail.gmail.com> <00e001c4bc3b$47269620$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 27 Oct 2004 16:40:20 +0100, Mark Birbeck wrote: > As you can see here, the first entry comes from Blogger.com, and the second > from a Wiki maintained using Atom. Each could have different authentication > mechanisms, and until I try to save my changes -- and get a 401 -- I can't > find out what they are. I understand that different implementations could have different authentication mechanisms. Do you have a proposal for how to address this besides the traditional 401 mechanism built into HTTP? Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Oct 27 14:21:44 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 OAA29114 for ; Wed, 27 Oct 2004 14:21:43 -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 i9RI9Wdn025271; Wed, 27 Oct 2004 11:09: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 i9RI9WrW025270; Wed, 27 Oct 2004 11:09:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RI9W8Y025246 for ; Wed, 27 Oct 2004 11:09:32 -0700 (PDT) (envelope-from gstein@google.com) Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34]) by stewie.corp.google.com (8.12.11/8.12.11) with ESMTP id i9RI9OfO018606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2004 11:09:25 -0700 Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4) id 1CMsEe-00007w-Uo by authid ; Wed, 27 Oct 2004 11:09:24 -0700 Date: Wed, 27 Oct 2004 11:09:24 -0700 From: Greg Stein To: Mark Birbeck Cc: atom-syntax@imc.org Subject: Re: Speifying mechanisms [was RE: XML2004Hackathon] Message-ID: <20041027180924.GE19301@google.com> References: <3f1451f504102609164cb2546e@mail.gmail.com> <009301c4bc0e$433f9160$6701a8c0@W100> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009301c4bc0e$433f9160$6701a8c0@W100> X-URL: http://www.lyra.org/greg/ User-Agent: Mutt/1.5.5.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 27, 2004 at 11:18:06AM +0100, Mark Birbeck wrote: >... > > That's what a status code of 401 and the > > WWW-Authenticate: header are for. > > Yes, but that's incredibly long-winded ... you have to fail before you know > how to succeed. But that is exactly how HTTP is specified, and how it has worked for many years. I don't see the need to redesign that or come up with other solutions. Note that some clients have a way to cache authentication information and they'll proactively supply it to the server when they connect (which saves the round-trip you mention). IMO, I don't see this as a problem. This is simply how HTTP works. >... > (Note also that WWW-Authenticate is protocol dependent, which -- so far -- > much of Atom is not.) The Atom publishing protocol *is* HTTP specific. Completely. I haven't heard of any desire nor attempt to deal with protocols other than HTTP. So I'd suggest that being "specific" is not a problem. Cheers, -g From owner-atom-syntax@mail.imc.org Wed Oct 27 15:02: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 PAA02246 for ; Wed, 27 Oct 2004 15:02:32 -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 i9RIgxgZ032234; Wed, 27 Oct 2004 11:42:59 -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 i9RIgxHt032233; Wed, 27 Oct 2004 11:42:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S009 ([195.40.123.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RIgw0K032214 for ; Wed, 27 Oct 2004 11:42:58 -0700 (PDT) (envelope-from mark.birbeck@x-port.net) Received: FROM [192.168.1.103] BY S009 with hMailServer ; 27-Oct-2004 19:42:50 +0100 From: "Mark Birbeck" To: "'Greg Stein'" Cc: Subject: RE: Speifying mechanisms Date: Wed, 27 Oct 2004 19:42:35 +0100 Message-ID: <00fc01c4bc54$bcea4140$6701a8c0@W100> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <20041027180924.GE19301@google.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RIgx0K032228 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greg, > > (Note also that WWW-Authenticate is protocol dependent, which -- so > >far -- much of Atom is not.) > > The Atom publishing protocol *is* HTTP specific. Completely. > I haven't heard of any desire nor attempt to deal with > protocols other than HTTP. So I'd suggest that being > "specific" is not a problem. OK .... I'd like to see Atom less protocol-dependent. ;) Many of the services around at the moment already offer the ability to blog via email, for example. How is that specified in Atom? From what you've said, it just isn't. Anyone that offers such a feature simply 'steps outside' of the Atom protocol. That doesn't bode well for the future, as people add blogging via mobile phone, email, SMS messages, or whatever. Surely we need to be able to express end-points dynamically? As of today, our XForms processor can already 'submit' XML documents in many different ways from the same form, including via SMTP. So, we could easily extend our formsPlayer blogging client demo to send updates via email by a simple change in the submission element -- no additional code. Except we can't, because we currently could not get the end-point information at run-time, and so would need to hard-code the email address. I realise it's not completely trivial to add such a feature, but I suggest it's worth considering how dependent Atom should be on HTTP if Atom is to fulfil its promise. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ Download our XForms processor from http://www.formsPlayer.com/ From owner-atom-syntax@mail.imc.org Wed Oct 27 16:14: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 QAA09468 for ; Wed, 27 Oct 2004 16:14: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 i9RK3jAG050521; Wed, 27 Oct 2004 13:03:45 -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 i9RK3jxJ050520; Wed, 27 Oct 2004 13:03:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RK3hgA050487 for ; Wed, 27 Oct 2004 13:03:44 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 43304 messnum 7734806 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 27 Oct 2004 20:03:42 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail01.svc.cra.dublin.eircom.net (qp 43304) with SMTP; 27 Oct 2004 20:03:42 -0000 Message-ID: <417FFF1C.8020107@dehora.net> Date: Wed, 27 Oct 2004 21:03:40 +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@imc.org Subject: Re: Speifying mechanisms References: <00fc01c4bc54$bcea4140$6701a8c0@W100> In-Reply-To: <00fc01c4bc54$bcea4140$6701a8c0@W100> 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 Mark Birbeck wrote: > OK .... I'd like to see Atom less protocol-dependent. ;) > > Many of the services around at the moment already offer the ability to blog > via email, for example. How is that specified in Atom? From what you've > said, it just isn't. Anyone that offers such a feature simply 'steps > outside' of the Atom protocol. That doesn't bode well for the future, as > people add blogging via mobile phone, email, SMS messages, or whatever. > Surely we need to be able to express end-points dynamically? > > [...] > > I realise it's not completely trivial to add such a feature, but I suggest > it's worth considering how dependent Atom should be on HTTP if Atom is to > fulfil its promise. Pedantry: Atom isn't depedendent on HTTP - it's a data format and as far as I can tell is neutral to transport and application protocols. The Atom protocol otoh is designed to work smoothly with HTTP; perhaps it should be renamed Atom-over-HTTP to avoid confusion. Seeking protocol neutrality in a protocol spec at the level we're talking about (HTTP, SMTP, Jabber, SMS) invites us to make the same kinds of mistakes that the WS family of specs has made and is currently tried to dig itself out of. Having seen how things are working out on that front, I'd like to avoid us repeating the same mistakes. cheers Bill From owner-atom-syntax@mail.imc.org Wed Oct 27 18:32: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 SAA23588 for ; Wed, 27 Oct 2004 18:32: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 i9RMCQYv079486; Wed, 27 Oct 2004 15:12:26 -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 i9RMCQFK079485; Wed, 27 Oct 2004 15:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RMCPxp079479 for ; Wed, 27 Oct 2004 15:12:25 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9RMCUui004901 for ; Wed, 27 Oct 2004 16:12:30 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I69009U2KCTCX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 27 Oct 2004 16:12:30 -0600 (MDT) Received: from [65.38.149.60] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6900LEXKCT21@mail.sun.net> for atom-syntax@imc.org; Wed, 27 Oct 2004 16:12:29 -0600 (MDT) Date: Wed, 27 Oct 2004 15:13:06 -0700 From: Tim Bray Subject: Re: RFC2396bis now a Full Standard In-reply-to: <52896A3A-25ED-11D9-9657-000A95A51C9E@sun.com> To: Tim Bray Cc: Joe Gregorio , Atom Syntax Message-id: <6096A09E-2865-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3f1451f504102113326265c37a@mail.gmail.com> <52896A3A-25ED-11D9-9657-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 24, 2004, at 11:48 AM, Tim Bray wrote: >> Given that RFC2396bis is now a full standard should we update the >> format and publication protocol specs to follow? > > Oh, yes please, let's do that immediately, and everyone take a moment > to think kind thoughts about Roy Fielding, who did the huge amount of > gruntwork required -Tim Sam asked me to say this officially, so I think the editors should now clean up all URI-talk in our drafts to reference 2396bis gets and as a side-effect mark PaceUriOrItsSuccessor closed. Anyone disagree? -Tim From owner-atom-syntax@mail.imc.org Thu Oct 28 08:02: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 IAA05366 for ; Thu, 28 Oct 2004 08:02:29 -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 i9SBjWpQ046160; Thu, 28 Oct 2004 04:45: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 i9SBjWpm046159; Thu, 28 Oct 2004 04:45:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SBjVs6046149 for ; Thu, 28 Oct 2004 04:45:31 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9SBl1G2022678 for ; Thu, 28 Oct 2004 04:47:02 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i9SBiLZn001450 for ; Thu, 28 Oct 2004 06:44:22 -0500 Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id i9SBjZ5j026325; Thu, 28 Oct 2004 06:45:35 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0I6A00420LZZEC@ims1.labs.mot.com>; Thu, 28 Oct 2004 06:45:35 -0500 (CDT) Date: Thu, 28 Oct 2004 06:45:35 -0500 From: Brett Lindsley Subject: Re: Speifying mechanisms To: Mark Birbeck Cc: "'Greg Stein'" , atom-syntax@imc.org Message-id: <4180DBDF.1070200@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0b5lmDpjvJ+yv2Thf52mog)" X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <00fc01c4bc54$bcea4140$6701a8c0@W100> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary_(ID_0b5lmDpjvJ+yv2Thf52mog) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT Mark, I have also been having similar thoughts on Atom bindings to protocols. An example I made in passing some time ago (one that I have a lot of working experience with) is a comparison to SyncML specs. SyncML specifies the protocol (MSCs) and document syntax, but then has several bindings to different protocols ( HTTP *and* OBEX). I also believe Atom specifications should decouple the protocol/syntax from the actual protocols and object framing to make it more flexible and future-proof it. This would make Atom more flexible.As a silly example, one could run OBEX over TCPIP (port 650) with Atom on top of OBEX. Brett Lindsley, Motorola Labs Mark Birbeck wrote: >Greg, > > > >>>(Note also that WWW-Authenticate is protocol dependent, which -- so >>>far -- much of Atom is not.) >>> >>> >>The Atom publishing protocol *is* HTTP specific. Completely. >>I haven't heard of any desire nor attempt to deal with >>protocols other than HTTP. So I'd suggest that being >>"specific" is not a problem. >> >> > >OK .... I'd like to see Atom less protocol-dependent. ;) > >Many of the services around at the moment already offer the ability to blog >via email, for example. How is that specified in Atom? From what you've >said, it just isn't. Anyone that offers such a feature simply 'steps >outside' of the Atom protocol. That doesn't bode well for the future, as >people add blogging via mobile phone, email, SMS messages, or whatever. >Surely we need to be able to express end-points dynamically? > >As of today, our XForms processor can already 'submit' XML documents in many >different ways from the same form, including via SMTP. So, we could easily >extend our formsPlayer blogging client demo to send updates via email by a >simple change in the submission element -- no additional code. Except we >can't, because we currently could not get the end-point information at >run-time, and so would need to hard-code the email address. > >I realise it's not completely trivial to add such a feature, but I suggest >it's worth considering how dependent Atom should be on HTTP if Atom is to >fulfil its promise. > >Regards, > >Mark > > >Mark Birbeck >CEO >x-port.net Ltd. > >e: Mark.Birbeck@x-port.net >t: +44 (0) 20 7689 9232 >w: http://www.formsPlayer.com/ > >Download our XForms processor from >http://www.formsPlayer.com/ > > > > > > --Boundary_(ID_0b5lmDpjvJ+yv2Thf52mog) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Mark,

I have also been having similar thoughts on Atom bindings to protocols. An example I
made in passing some time ago (one that I have a lot of working experience with) is a
comparison to SyncML specs. SyncML specifies the protocol (MSCs) and document syntax,
but then has several bindings to different protocols ( HTTP *and* OBEX).

I also believe Atom specifications should decouple the protocol/syntax from the actual
protocols and object framing to make it more flexible and future-proof it. This would make
Atom more flexible.As a silly example, one could run OBEX over TCPIP (port 650)
with Atom on top of OBEX.

Brett Lindsley, Motorola Labs


Mark Birbeck wrote:
--Boundary_(ID_0b5lmDpjvJ+yv2Thf52mog)-- From owner-atom-syntax@mail.imc.org Thu Oct 28 08:16: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 IAA06418 for ; Thu, 28 Oct 2004 08:16: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 i9SC2pYk047553; Thu, 28 Oct 2004 05:02:51 -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 i9SC2p0W047552; Thu, 28 Oct 2004 05:02:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SC2oQi047542 for ; Thu, 28 Oct 2004 05:02:51 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1035950wri for ; Thu, 28 Oct 2004 05:02:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nx9i8W3DLg4FADr45Qbo9NcWVcHwoKnR5Y/P+FsGTB7/1vWszIKXGpc+rgwq6CbObdT3YDGoRkSI6dnilw3S6fM3NEQubqIfpLZ5hx7MtuSOmNG7o0K2PMzvOab6vIwjiec+BYUmmG5jsgQ2VkHUj8h5iKy2UMY/9FcLtpS3F0w= Received: by 10.38.149.71 with SMTP id w71mr1318045rnd; Thu, 28 Oct 2004 05:02:55 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Thu, 28 Oct 2004 05:02:55 -0700 (PDT) Message-ID: <3f1451f50410280502c996010@mail.gmail.com> Date: Thu, 28 Oct 2004 08:02:55 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Brett Lindsley Subject: Re: Speifying mechanisms Cc: Mark Birbeck , Greg Stein , atom-syntax@imc.org In-Reply-To: <4180DBDF.1070200@labs.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <00fc01c4bc54$bcea4140$6701a8c0@W100> <4180DBDF.1070200@labs.mot.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From our charter[1]: "The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol." [1] http://www.ietf.org/html.charters/atompub-charter.html -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Oct 28 13:42:23 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 NAA29382 for ; Thu, 28 Oct 2004 13:42:22 -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 i9SHUGbB090360; Thu, 28 Oct 2004 10:30: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 i9SHUGw6090359; Thu, 28 Oct 2004 10:30:16 -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 i9SHUBEP090332 for ; Thu, 28 Oct 2004 10:30:16 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.104] (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 i9SHVQHE019536 for ; Thu, 28 Oct 2004 13:31:27 -0400 Message-ID: <41812CA8.6090501@intertwingly.net> Date: Thu, 28 Oct 2004 13:30:16 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: New AtomPubIssuesList for 2004/10/28 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> In-Reply-To: <4166C99A.4040603@intertwingly.net> 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 Lets see if we can do some small cleanups: The next date element with the most sponsors: PaceDateModified Making link not required (in some circumstances): PaceContentOrLink PaceOptionalAlternateLink Error reporting: PaceErrVerb PaceServiceError Host from mod-wiki: PacePersonConstructs - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 28 14:48:33 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 OAA13801 for ; Thu, 28 Oct 2004 14:48:32 -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 i9SIYROD005919; Thu, 28 Oct 2004 11:34:27 -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 i9SIYRe2005918; Thu, 28 Oct 2004 11:34:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SIYQwM005899 for ; Thu, 28 Oct 2004 11:34:27 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so30882rnb for ; Thu, 28 Oct 2004 11:34:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Z1Of3kFV+go3Fwhuwvyh3cjp8ROwbQBVTSvHxQK5ZNaJA6E/oz1BxntOP/VQBibq6AySD+IL7FO/9dwzMfNU3cRRqi5aji5/+VyRNi7QnNW2CDQ2vyFIDctyaGn+R8FR8jnZf/MzJLf7kzeXC5qEegd1US6VFzunMDubpDd8Z5o= Received: by 10.38.98.18 with SMTP id v18mr1108732rnb; Thu, 28 Oct 2004 11:34:30 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 11:34:30 -0700 (PDT) Message-ID: <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> Date: Thu, 28 Oct 2004 20:34:30 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: New AtomPubIssuesList for 2004/10/28 Cc: Atom-Syntax In-Reply-To: <41812CA8.6090501@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit PaceDateModified +1 PaceContentOrLink -1 PaceOptionalAlternateLink +1 PaceErrVerb -1 PaceServiceError +1 PacePersonConstructs +1 Reasons: PaceDateModified - atom:updated is very loose, this is tighter (the naming is likely to cause confusion, but atom:updated is already in the bag) PaceContentOrLink - this seems a bit clunky, and already covered by PaceOptionalAlternateLink PaceOptionalAlternateLink - all the use cases on the Wiki PaceErrVerb - probably has virtue, but pragmatically I think it's out of Atom's scope PaceServiceError - worth a try PacePersonConstructs - this does seem rather kludgey, but I think the Wiki use case is strong Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 28 14:56:13 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 OAA15994 for ; Thu, 28 Oct 2004 14:56:12 -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 i9SIo3Um009418; Thu, 28 Oct 2004 11:50:03 -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 i9SIo3In009417; Thu, 28 Oct 2004 11:50:03 -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 i9SIo2p9009411 for ; Thu, 28 Oct 2004 11:50:03 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.104] (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 i9SIpEI9024047; Thu, 28 Oct 2004 14:51:14 -0400 Message-ID: <41813F5C.3030603@intertwingly.net> Date: Thu, 28 Oct 2004 14:50:04 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom-Syntax Subject: PaceOptionalAlternateLink References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> In-Reply-To: <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> 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 Danny Ayers wrote: > > PaceContentOrLink > - this seems a bit clunky, and already covered by PaceOptionalAlternateLink > > PaceOptionalAlternateLink > - all the use cases on the Wiki I'm -1 on making AlternateLink completely optional unless the content is provided. The use cases on the wiki seem to all include inline content. Is there a use case for syndication where the content is neither included nor referenced? As I see it PaceContentOrLink coupled with PaceReformedContent3 (already approved) provide consumers with a minimum set of guarantees: 1) All entries will have a displayable text fallback 2) The content is either inline or can be located - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 28 15:14:12 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 PAA19709 for ; Thu, 28 Oct 2004 15:14:12 -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 i9SJ5aJo013180; Thu, 28 Oct 2004 12:05:36 -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 i9SJ5aYM013179; Thu, 28 Oct 2004 12:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJ5ZbV013172 for ; Thu, 28 Oct 2004 12:05:35 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9SJ5lui012328 for ; Thu, 28 Oct 2004 13:05:47 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6B009CJ6DMRD@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 28 Oct 2004 13:05:46 -0600 (MDT) Received: from [65.38.149.108] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6B00H4J6DMD6@mail.sun.net> for atom-syntax@imc.org; Thu, 28 Oct 2004 13:05:46 -0600 (MDT) Date: Thu, 28 Oct 2004 12:06:28 -0700 From: Tim Bray Subject: PaceDateModified To: Atom Syntax Message-id: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT -1 Absolutely, I'm lying down in the road here. This is *compulsory*. As a publisher, I do not accept that, as a condition of publishing Atom, I am obligated to tell the world every time I make a spelling correction or trivial update. This is a totally unreasonable proposition. In point of real-life fact, the publisher decides when a change is a change, and PaceDateUpdated respects that reality. Make it optional and I'll reconsider. -Tim From owner-atom-syntax@mail.imc.org Thu Oct 28 15:15: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 PAA19894 for ; Thu, 28 Oct 2004 15:15:15 -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 i9SJ8Pfx014019; Thu, 28 Oct 2004 12:08:25 -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 i9SJ8PhC014018; Thu, 28 Oct 2004 12:08:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJ8O1c014010 for ; Thu, 28 Oct 2004 12:08:24 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so32828rnb for ; Thu, 28 Oct 2004 12:08:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=PAqknGJz/MWeQFV+CbimlBpf44Aor48IUFoz0gY05BBi3ZNo6nLQo1qaKrvenRGEZUJ6zhAvS4R24pyfaRfQOO47XVUlEHkE0hz5Lkypos7XkFfXur2k+JThn92/IQiUZo7bGvAfcjwwHHcGwK+KK98jc1V+2Jm7Urh3MHj7JWg= Received: by 10.38.12.80 with SMTP id 80mr1123492rnl; Thu, 28 Oct 2004 12:08:29 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 12:08:28 -0700 (PDT) Message-ID: <1f2ed5cd04102812081538d1b0@mail.gmail.com> Date: Thu, 28 Oct 2004 21:08:28 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: PaceOptionalAlternateLink Cc: Atom-Syntax In-Reply-To: <41813F5C.3030603@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> <41813F5C.3030603@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 28 Oct 2004 14:50:04 -0400, Sam Ruby wrote: > Is there a use case for syndication where the content is neither > included nor referenced? I'm not sure, this is drifting into protocol territory, but might it not be useful to use a no-content entry to signify removal of an existing entry? -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 28 15:16: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 PAA20078 for ; Thu, 28 Oct 2004 15:16:08 -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 i9SJ6JiX013483; Thu, 28 Oct 2004 12:06: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 i9SJ6J1F013482; Thu, 28 Oct 2004 12:06:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJ6AC9013406 for ; Thu, 28 Oct 2004 12:06:10 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9SJ6KNH006286 for ; Thu, 28 Oct 2004 13:06:20 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6B00DQ56EJFJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 28 Oct 2004 13:06:19 -0600 (MDT) Received: from [65.38.149.108] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6B00H4J6DMD6@mail.sun.net> for atom-syntax@imc.org; Thu, 28 Oct 2004 13:06:19 -0600 (MDT) Date: Thu, 28 Oct 2004 12:07:02 -0700 From: Tim Bray Subject: Re: PaceOptionalAlternateLink In-reply-to: <41813F5C.3030603@intertwingly.net> To: Sam Ruby Cc: Danny Ayers , Atom-Syntax Message-id: <8CD023DA-2914-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> <41813F5C.3030603@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 28, 2004, at 11:50 AM, Sam Ruby wrote: > I'm -1 on making AlternateLink completely optional unless the content > is provided. The use cases on the wiki seem to all include inline > content. Is there a use case for syndication where the content is > neither included nor referenced? > > As I see it PaceContentOrLink coupled with PaceReformedContent3 > (already approved) provide consumers with a minimum set of guarantees: +1. -Tim From owner-atom-syntax@mail.imc.org Thu Oct 28 15:31: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 PAA23070 for ; Thu, 28 Oct 2004 15:31: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 i9SJQow3020067; Thu, 28 Oct 2004 12:26: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 i9SJQooK020066; Thu, 28 Oct 2004 12:26:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJQnxa020060 for ; Thu, 28 Oct 2004 12:26:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so33777rnb for ; Thu, 28 Oct 2004 12:26:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HgSqBPv0CGwVe9jTHRHTKDBDeruxlyraYzf2nB291C5gdA0VS9x/xMcO6H+6gKJEquWpYINalg96oIKvTUtT7RbFFUHsUM5LXNs40nqZa2kvA6sjljBchtng3Fuv+2la9Gwv0qGXisLJDKmmC8yUB63D0H+QaaGzktSIv+ydg/4= Received: by 10.38.98.18 with SMTP id v18mr1134970rnb; Thu, 28 Oct 2004 12:26:44 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 12:26:44 -0700 (PDT) Message-ID: <1f2ed5cd04102812261d6016dd@mail.gmail.com> Date: Thu, 28 Oct 2004 21:26:44 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: PaceDateModified Cc: Atom Syntax In-Reply-To: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 28 Oct 2004 12:06:28 -0700, Tim Bray wrote: > This is *compulsory*. As a publisher, I do not accept that, as a > condition of publishing Atom, I am obligated to tell the world every > time I make a spelling correction or trivial update. This is a totally > unreasonable proposition. In point of real-life fact, the publisher > decides when a change is a change, and PaceDateUpdated respects that > reality. The publisher corrects a spelling mistake and it goes into the feed - isn't that the real-life fact? So why shouldn't the publishing software give the client software a helping hand, and give it explicit notification? What of the Winerwatch offend-and-delete scenario? Shouldn't the publisher have at least the obligation to say something has changed? > Make it optional and I'll reconsider. -Tim Devil's advocacy above. I wouldn't oppose it being optional (and certainly wouldn't want to ding my tailpipe). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 28 15:32:23 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 PAA23253 for ; Thu, 28 Oct 2004 15:32:22 -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 i9SJQ3XA019846; Thu, 28 Oct 2004 12:26:03 -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 i9SJQ3CP019845; Thu, 28 Oct 2004 12:26:03 -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 i9SJQ2pc019809 for ; Thu, 28 Oct 2004 12:26:02 -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 1CNFuS-0003sO-GI; Thu, 28 Oct 2004 19:26:08 +0000 Message-ID: <418147CD.5090703@franklinmint.fm> Date: Thu, 28 Oct 2004 15:26:05 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> In-Reply-To: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > -1 Absolutely, I'm lying down in the road here. > ... > > Make it optional and I'll reconsider. -Tim > -1 even if it's optional. This is protocol-level data. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 28 15:33:33 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 PAA23587 for ; Thu, 28 Oct 2004 15:33: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 i9SJNs9Z019307; Thu, 28 Oct 2004 12:23:54 -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 i9SJNsp5019306; Thu, 28 Oct 2004 12:23:54 -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 i9SJNrLk019274 for ; Thu, 28 Oct 2004 12:23:53 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.104] (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 i9SJOiYX026195; Thu, 28 Oct 2004 15:24:44 -0400 Message-ID: <41814736.8060505@intertwingly.net> Date: Thu, 28 Oct 2004 15:23:34 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom-Syntax Subject: Re: PaceOptionalAlternateLink References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> <41813F5C.3030603@intertwingly.net> <1f2ed5cd04102812081538d1b0@mail.gmail.com> In-Reply-To: <1f2ed5cd04102812081538d1b0@mail.gmail.com> 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 Danny Ayers wrote: > On Thu, 28 Oct 2004 14:50:04 -0400, Sam Ruby wrote: > >> Is there a use case for syndication where the content is neither >>included nor referenced? > > I'm not sure, this is drifting into protocol territory, but might it > not be useful to use a no-content entry to signify removal of an > existing entry? I believe that's what the DELETE method is used for. In any case, if content is not provided, then summary is required. Having a summary with no way to locate the content seems a bit... strange. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 28 15:34: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 PAA23836 for ; Thu, 28 Oct 2004 15:34:24 -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 i9SJSUeG020593; Thu, 28 Oct 2004 12:28:30 -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 i9SJSUeQ020592; Thu, 28 Oct 2004 12:28:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJST4P020586 for ; Thu, 28 Oct 2004 12:28:30 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so30261rnk for ; Thu, 28 Oct 2004 12:28:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=SRUFReRJ7vK44zK9XHcDjkaX+44eppTEoAHe+q7XN1JJkquU7LvcKQqayCZDxzVQyWD5HLb7HOGMCaNyVav2QvFzeszwWZyE+GuBHxPIRBnqBGnu8TCD0waC5FzX2SagsoTyKxnWp2wMrRtRNXNhCwBni3EUn2e9RCTFOS6X+FE= Received: by 10.38.98.30 with SMTP id v30mr1128223rnb; Thu, 28 Oct 2004 12:28:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 12:28:39 -0700 (PDT) Message-ID: <1f2ed5cd04102812287b04b015@mail.gmail.com> Date: Thu, 28 Oct 2004 21:28:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: PaceOptionalAlternateLink Cc: Atom-Syntax In-Reply-To: <41814736.8060505@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <1f2ed5cd04102811344aeb6f1b@mail.gmail.com> <41813F5C.3030603@intertwingly.net> <1f2ed5cd04102812081538d1b0@mail.gmail.com> <41814736.8060505@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 28 Oct 2004 15:23:34 -0400, Sam Ruby wrote: > Danny Ayers wrote: > > I'm not sure, this is drifting into protocol territory, but might it > > not be useful to use a no-content entry to signify removal of an > > existing entry? > > I believe that's what the DELETE method is used for. Other direction. > In any case, if content is not provided, then summary is required. > Having a summary with no way to locate the content seems a bit... strange. True. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 28 15:52:33 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 PAA27928 for ; Thu, 28 Oct 2004 15:52: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 i9SJh9kC025451; Thu, 28 Oct 2004 12:43:09 -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 i9SJh9LE025450; Thu, 28 Oct 2004 12:43:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJh8HA025444 for ; Thu, 28 Oct 2004 12:43:08 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (webmail08-en1 [10.13.11.150]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i9SJhJIP004485; Thu, 28 Oct 2004 12:43:20 -0700 (PDT) Received: from webmail08 (localhost [127.0.0.1]) by mac.com (Xserve/webmail08/MantshX 4.0) with ESMTP id i9SJhJNI017557; Thu, 28 Oct 2004 12:43:19 -0700 (PDT) Message-ID: <11602367.1098992599478.JavaMail.dtcd@mac.com> Date: Thu, 28 Oct 2004 20:43:19 +0100 From: Graham To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: atom-syntax@imc.org in-reply-to: <418147CD.5090703@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit references: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> X-Originating-IP: 161.73.18.96/instID=37 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, October 28, 2004, at 08:32PM, Robert Sayre wrote: >-1 even if it's optional. This is protocol-level data. +1 to that. The only suggested use cases have been about caching etc. Graham From owner-atom-syntax@mail.imc.org Thu Oct 28 16:47:13 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 QAA08189 for ; Thu, 28 Oct 2004 16:47:12 -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 i9SKdqmV038721; Thu, 28 Oct 2004 13:39: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 i9SKdqBK038720; Thu, 28 Oct 2004 13:39:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SKdpBF038713 for ; Thu, 28 Oct 2004 13:39:52 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so37724rnb for ; Thu, 28 Oct 2004 13:39:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=a0VwUETA80Zv7OB+ydbBza+sBlayVR+5VnJcEvr7D6TncG4u+a1KENMoLCJhMQT8StAUgPEbgoRRDv08ZA4Q4z9SEPHY0OY9p1fcKaiS8IYJHjRrqndYkWDIVTKdbj03RmJAO9wo1iA8Ih5y4JfwJD3YR5qSYMh/WEpaZCfUQDQ= Received: by 10.38.98.18 with SMTP id v18mr1172811rnb; Thu, 28 Oct 2004 13:39:50 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 13:39:50 -0700 (PDT) Message-ID: <1f2ed5cd04102813396bad52bd@mail.gmail.com> Date: Thu, 28 Oct 2004 22:39:50 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: PaceDateModified Cc: mint@franklinmint.fm, atom-syntax@imc.org In-Reply-To: <11602367.1098992599478.JavaMail.dtcd@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 28 Oct 2004 20:43:19 +0100, Graham wrote: > > On Thursday, October 28, 2004, at 08:32PM, Robert Sayre wrote: > > >-1 even if it's optional. This is protocol-level data. > > > +1 to that. The only suggested use cases have been about caching etc. Consider a situation where I'm getting entries indirectly from a variety of other sources: entry atom:updated = 10:30pm contains a spelling mistake entry atom:updated = 10:30pm is fixed Which do I choose? Yes, this is protocol and cache-related. But the question remains, which do I choose? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 28 16:48:09 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 QAA08447 for ; Thu, 28 Oct 2004 16:48: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 i9SKfm5j038919; Thu, 28 Oct 2004 13:41: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 i9SKfmdf038918; Thu, 28 Oct 2004 13:41:48 -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 i9SKflnt038877 for ; Thu, 28 Oct 2004 13:41:48 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 217A67C2EA; Thu, 28 Oct 2004 22:38:09 +0200 (CEST) Date: Thu, 28 Oct 2004 22:43:26 +0200 To: "Tim Bray" Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.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: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 28 Oct 2004 12:06:28 -0700, Tim Bray wrote: > As a publisher, I do not accept that, as a condition of publishing > Atom, I am obligated to tell the world every time I make a spelling > correction or trivial update. You most often do this already in the HTTP protocol's 'Last-Modified' header. Why refuse to duplicate this value into the entry whenevery you change it? The reason 'Last-Modified' isn't enough, is as I see it: 1. Not all entries are retreivable outside a feed. They only exist in the feed they're published in, and may not even have an alternate representation (that is directly retreivable over HTTP or other protocols that has a notion of «last modified»). 2. The feeds (and entries) might be served dynamically. Dynamically served content seldom provides the correct 'Last-Modified' date of the resource. -- 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 Thu Oct 28 17:05:12 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 RAA12943 for ; Thu, 28 Oct 2004 17:05:12 -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 i9SKtmcv041798; Thu, 28 Oct 2004 13:55: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 i9SKtmML041797; Thu, 28 Oct 2004 13:55:48 -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 i9SKtlSE041791 for ; Thu, 28 Oct 2004 13:55:48 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.104] (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 i9SKv5nG032484; Thu, 28 Oct 2004 16:57:07 -0400 Message-ID: <41815CDC.3050603@intertwingly.net> Date: Thu, 28 Oct 2004 16:55:56 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> In-Reply-To: <418147CD.5090703@franklinmint.fm> 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 Robert Sayre wrote: > > Tim Bray wrote: > >> -1 Absolutely, I'm lying down in the road here. >> > ... > >> Make it optional and I'll reconsider. -Tim > > -1 even if it's optional. This is protocol-level data. But... a feed can contain multiple atom:entries. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Oct 28 17:09: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 RAA13633 for ; Thu, 28 Oct 2004 17:09: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 i9SL2tYU043973; Thu, 28 Oct 2004 14:02: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 i9SL2t2r043972; Thu, 28 Oct 2004 14:02:55 -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 i9SL2taG043963 for ; Thu, 28 Oct 2004 14:02:55 -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 1CNHQC-0005Aj-Ja; Thu, 28 Oct 2004 21:03:00 +0000 Message-ID: <41815E7F.1030507@franklinmint.fm> Date: Thu, 28 Oct 2004 17:02:55 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Graham , atom-syntax@imc.org Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> In-Reply-To: <1f2ed5cd04102813396bad52bd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sam Ruby wrote: > But... a feed can contain multiple atom:entries. > > Asbjørn Ulsberg wrote: > > The reason 'Last-Modified' isn't enough, is as I see it: > > 1. Not all entries are retreivable outside a feed. Aggregators just restore entries when they appear in feeds, AFAIK. Our two most active aggregator authoring participants don't see a need for it.[0] Duplicating protocol data as an optimization would be worth considering if there was a big payoff. Aggregator authors don't see one, so who are we helping? Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg07645.html From owner-atom-syntax@mail.imc.org Thu Oct 28 17:25:33 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 RAA15982 for ; Thu, 28 Oct 2004 17:25: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 i9SLJjqp047361; Thu, 28 Oct 2004 14:19:45 -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 i9SLJjHp047360; Thu, 28 Oct 2004 14:19:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40826.mail.yahoo.com (web40826.mail.yahoo.com [66.218.92.73]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9SLJi3K047273 for ; Thu, 28 Oct 2004 14:19:44 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041028211950.36907.qmail@web40826.mail.yahoo.com> Received: from [131.107.71.224] by web40826.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 14:19:50 PDT Date: Thu, 28 Oct 2004 14:19:50 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Graham , mint@franklinmint.fm Cc: atom-syntax@imc.org In-Reply-To: <11602367.1098992599478.JavaMail.dtcd@mac.com> 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: --- Graham wrote: > > >-1 even if it's optional. This is protocol-level > data. > > > +1 to that. The only suggested use cases have been > about caching etc. +1 to that as well (i.e. -1 to PaceDateModified) Having atom:updated makes atom:modified unnecessary except for edge cases which to me shouldn't be catered to in the core. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 28 17:40:28 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 RAA19314 for ; Thu, 28 Oct 2004 17:40:27 -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 i9SLUFOt049968; Thu, 28 Oct 2004 14:30: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 i9SLUFVO049967; Thu, 28 Oct 2004 14:30:15 -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 i9SLUESf049949 for ; Thu, 28 Oct 2004 14:30:14 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 60FC47C2E9; Thu, 28 Oct 2004 23:26:45 +0200 (CEST) Date: Thu, 28 Oct 2004 23:31:05 +0200 To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: Atom-Syntax References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <41815E7F.1030507@franklinmint.fm> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 28 Oct 2004 17:02:55 -0400, Robert Sayre wrote: > Duplicating protocol data [...] If you read my whole post, and Sam Ruby's comment to this, you'd note that this isn't always available in the protocol either. Entries may appear only in feeds, which means that there are absolutely no protocol metadata available for them, whatsoever. Where should you look for 'Last-Modified' information when you can't get it from HTTP? -- 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 Thu Oct 28 17:47: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 RAA20573 for ; Thu, 28 Oct 2004 17:47: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 i9SLdR0o052251; Thu, 28 Oct 2004 14:39:27 -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 i9SLdRpq052250; Thu, 28 Oct 2004 14:39:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SLdQM4052242 for ; Thu, 28 Oct 2004 14:39:26 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so40643rnb for ; Thu, 28 Oct 2004 14:39:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=aWRu7Z0qZrN0NZI9rZZtyJAIQHCNqU2uwEWPPPI119TtHemj0GzTWWeIh7x4kKrpEQ8MXxpL+61rt8A4mQk3HWgEoFBza25TVmOHQr2WyYszPsBUjKq8F+TWP1lbc4z5ReJ8ft4WjXct8KgvcZMcvffUFphIgBtOxA9EosaQCbo= Received: by 10.38.98.18 with SMTP id v18mr1202319rnb; Thu, 28 Oct 2004 14:39:27 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 14:39:27 -0700 (PDT) Message-ID: <1f2ed5cd0410281439290575fa@mail.gmail.com> Date: Thu, 28 Oct 2004 23:39:27 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: Graham , atom-syntax@imc.org In-Reply-To: <41815E7F.1030507@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 28 Oct 2004 17:02:55 -0400, Robert Sayre wrote: > Sam Ruby wrote: Our > two most active aggregator authoring participants don't see a need for > it.[0] Sorry Sam, but the post you link to says: "...a model like NetNewsWire that shows the differences using an HTML diff." > [0] http://www.imc.org/atom-syntax/mail-archive/msg07645.html -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Oct 28 18:01:19 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 SAA23414 for ; Thu, 28 Oct 2004 18:01: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 i9SLsKIM055821; Thu, 28 Oct 2004 14:54: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 i9SLsKOo055820; Thu, 28 Oct 2004 14:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40809.mail.yahoo.com (web40809.mail.yahoo.com [66.218.78.186]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9SLsKaQ055794 for ; Thu, 28 Oct 2004 14:54:20 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041028215428.96072.qmail@web40809.mail.yahoo.com> Received: from [131.107.71.95] by web40809.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 14:54:28 PDT Date: Thu, 28 Oct 2004 14:54:28 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: "Asbjørn" Ulsberg , mint@franklinmint.fm Cc: Atom-Syntax In-Reply-To: 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: --- Asbjørn Ulsberg wrote: > > > Where should you look for 'Last-Modified' > information when you can't get > it from HTTP? The real question is why you'd be looking for "last modified" information from an entry in the first place when atom:updated exists. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 28 18:11: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 SAA25698 for ; Thu, 28 Oct 2004 18:11:15 -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 i9SM3tfJ058104; Thu, 28 Oct 2004 15:03: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 i9SM3tnW058103; Thu, 28 Oct 2004 15:03:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40809.mail.yahoo.com (web40809.mail.yahoo.com [66.218.78.186]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9SM3s9R058079 for ; Thu, 28 Oct 2004 15:03:54 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041028220402.97498.qmail@web40809.mail.yahoo.com> Received: from [131.107.71.227] by web40809.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 15:04:02 PDT Date: Thu, 28 Oct 2004 15:04:02 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Danny Ayers , mint@franklinmint.fm Cc: Graham , atom-syntax@imc.org In-Reply-To: <1f2ed5cd0410281439290575fa@mail.gmail.com> 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: --- Danny Ayers wrote: > > Our > > two most active aggregator authoring participants > don't see a need for > > it.[0] > > Sorry Sam, but the post you link to says: > > "...a model like NetNewsWire that shows the > differences using an HTML diff." Exactly. If I was going to have some way of showing users each minute change that occured to an entry then I'd simply run a diff between old and new each time I fetched the entry not test against some optional or mandatory last-modified element then "alert" the user. So as the the post said, I don't plan to use this element and even if I was going to implement a feature that targets the scenario this element is meant for I still wouldn't use it. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 28 18:11: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 SAA25714 for ; Thu, 28 Oct 2004 18:11:16 -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 i9SM469v058175; Thu, 28 Oct 2004 15:04: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 i9SM46Aw058174; Thu, 28 Oct 2004 15:04:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SM45IX058167 for ; Thu, 28 Oct 2004 15:04:05 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so41675rnb for ; Thu, 28 Oct 2004 15:04:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=pRNchwvfgXfrimnWg6AwgGVvb46grztM0NH3OQc7iIuSB5Qvre1TRKJ1Q+pa6BpEVhAHo2QvMYSLO9eHuDEx+nFyjvw1fwEJyfuf+yRod/o09sUX1D8aTzdfva+MVrfw7xAiHEdFwjlcPSMNDZAn9yIob85jn03FH0uzvBECX1o= Received: by 10.38.12.80 with SMTP id 80mr1210142rnl; Thu, 28 Oct 2004 15:04:13 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Thu, 28 Oct 2004 15:04:12 -0700 (PDT) Message-ID: <1f2ed5cd0410281504577c11f6@mail.gmail.com> Date: Fri, 29 Oct 2004 00:04:12 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Re: PaceDateModified In-Reply-To: <1f2ed5cd0410281439290575fa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> <1f2ed5cd0410281439290575fa@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit One question: if an aggegrator is designed to get the most-recently updated entries (which doesn't sound unreasonable), how will the user ever get to see spelling corrections and so on that have appeared after the atom:updated date? Cheers, Danny. btw, Movable Type also considers it useful information: http://www.movabletype.org/docs/mtmanual_tags.html#item_MTEntryModifiedDate From owner-atom-syntax@mail.imc.org Thu Oct 28 18:30:39 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 SAA00209 for ; Thu, 28 Oct 2004 18:30:38 -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 i9SMOEEl062434; Thu, 28 Oct 2004 15:24:14 -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 i9SMOEUQ062433; Thu, 28 Oct 2004 15:24:14 -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 i9SMODfp062427 for ; Thu, 28 Oct 2004 15:24:14 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNIgv-0002OJ-LP; Thu, 28 Oct 2004 22:24:23 +0000 Message-ID: <4181718E.40608@franklinmint.fm> Date: Thu, 28 Oct 2004 18:24:14 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > If you read my whole post, and Sam Ruby's comment to this, you'd note > that this isn't always available in the protocol either. Entries may > appear only in feeds, which means that there are absolutely no protocol > metadata available for them, whatsoever. > It's not that I didn't read and understand your post. I just think you're wrong. The feed delivery format isn't perfect, but sticking crufty date elements in the entries won't fix it. If per-entry protocol data is important to you, the best course of action is to figure out a protocol that delivers entries individually. A pipelined HTTP request might be one solution. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 28 18:35:11 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 SAA01128 for ; Thu, 28 Oct 2004 18:35:11 -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 i9SMS2AS063278; Thu, 28 Oct 2004 15:28: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 i9SMS2Ll063277; Thu, 28 Oct 2004 15:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40824.mail.yahoo.com (web40824.mail.yahoo.com [66.218.92.71]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9SMS1If063267 for ; Thu, 28 Oct 2004 15:28:01 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041028222809.37578.qmail@web40824.mail.yahoo.com> Received: from [131.107.71.94] by web40824.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 15:28:09 PDT Date: Thu, 28 Oct 2004 15:28:09 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Danny Ayers , atom-syntax@imc.org In-Reply-To: <1f2ed5cd0410281504577c11f6@mail.gmail.com> 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: --- Danny Ayers wrote: > > One question: if an aggegrator is designed to get > the most-recently > updated entries (which doesn't sound unreasonable), > how will the user > ever get to see spelling corrections and so on that > have appeared > after the atom:updated date? This has NOTHING to do with the atom:modified date. RSS Bandit, NetNewsWire and a bunch of other aggregators always show the user the most recently fetched content for the site. The only question is whether the aggregator decides whether to announce changes to the user based on some internal heuristic or some notice from the server that indicates the last time *anything* in the entry changed. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 28 19:46: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 TAA15939 for ; Thu, 28 Oct 2004 19:46: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 i9SNOvE1076706; Thu, 28 Oct 2004 16:24: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 i9SNOvnu076705; Thu, 28 Oct 2004 16:24:57 -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 i9SNOuSN076697 for ; Thu, 28 Oct 2004 16:24:56 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.104] (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 i9SNQGeC017185; Thu, 28 Oct 2004 19:26:16 -0400 Message-ID: <41817FD3.7050405@intertwingly.net> Date: Thu, 28 Oct 2004 19:25:07 -0400 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: mint@franklinmint.fm, atom-syntax@imc.org Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> <1f2ed5cd0410281439290575fa@mail.gmail.com> In-Reply-To: <1f2ed5cd0410281439290575fa@mail.gmail.com> 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 Danny Ayers wrote: > On Thu, 28 Oct 2004 17:02:55 -0400, Robert Sayre wrote: > >>Sam Ruby wrote: > > Our > >>two most active aggregator authoring participants don't see a need for >>it.[0] > > Sorry Sam, but the post you link to says: > > "...a model like NetNewsWire that shows the differences using an HTML diff." > >>[0] http://www.imc.org/atom-syntax/mail-archive/msg07645.html Note: that link was posted by Robert Sayre. My contribution to this thread was simply to point out that entry level information is not something I would expect to find at the protocol level. FYI: Mod speedyfeed[1] makes use of the atom:modified element. - Sam Ruby [1] http://asdf.blogs.com/asdf/2004/09/mod_speedyfeed__1.html From owner-atom-syntax@mail.imc.org Thu Oct 28 20:01: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 UAA20422 for ; Thu, 28 Oct 2004 20:01:54 -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 i9SNpu3N083908; Thu, 28 Oct 2004 16:51: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 i9SNpuad083907; Thu, 28 Oct 2004 16:51:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9SNppqE083870 for ; Thu, 28 Oct 2004 16:51:51 -0700 (PDT) (envelope-from rooneg@electricjellyfish.net) Received: (qmail 97119 invoked from network); 28 Oct 2004 23:52:01 -0000 Received: from ool-182c4fa2.dyn.optonline.net (HELO ?192.168.0.2?) (24.44.79.162) by relay01.pair.com with SMTP; 28 Oct 2004 23:52:01 -0000 X-pair-Authenticated: 24.44.79.162 Message-ID: <41818621.3040300@electricjellyfish.net> Date: Thu, 28 Oct 2004 19:52:01 -0400 From: Garrett Rooney User-Agent: Mozilla Thunderbird 0.8 (X11/20041012) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Danny Ayers , mint@franklinmint.fm, atom-syntax@imc.org Subject: Re: PaceDateModified References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> <1f2ed5cd0410281439290575fa@mail.gmail.com> <41817FD3.7050405@intertwingly.net> In-Reply-To: <41817FD3.7050405@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; 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 Sam Ruby wrote: > FYI: Mod speedyfeed[1] makes use of the atom:modified element. > > - Sam Ruby > > [1] http://asdf.blogs.com/asdf/2004/09/mod_speedyfeed__1.html True, but as it's author I'd also be just as happy with atom:updated as described in PaceDateUpdated. The point of delta encoding the feed is to only send down what the user needs to see. The publisher can just as well denote that with atom:updated as they can with atom:modified. As long as there's some way to say for each entry "has this changed since $DATE" I'll be happy, and I'm not too picky about the difference between "changed" and "changed in a way that matters to the reader". -garrett From owner-atom-syntax@mail.imc.org Thu Oct 28 20:10:12 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 UAA23113 for ; Thu, 28 Oct 2004 20:10:11 -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 i9T01DFI085621; Thu, 28 Oct 2004 17:01: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 i9T01DwW085620; Thu, 28 Oct 2004 17:01:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T01BMQ085488 for ; Thu, 28 Oct 2004 17:01:12 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 10:00:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 10:00:19 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 5:06 AM, "Tim Bray" wrote: > As a publisher, I do not accept that, as a > condition of publishing Atom, I am obligated to tell the world every > time I make a spelling correction or trivial update. You already do via http Date-Modified, and if you break that you break all sorts of http things. How is this different? If PubSub or similar finds two copies of an entry you made, identified by to be the same thing, but which are different in minor ways, how will it know which is most recent, and thus which one to propogate? e. From owner-atom-syntax@mail.imc.org Thu Oct 28 20:41:58 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 UAA00812 for ; Thu, 28 Oct 2004 20:41:57 -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 i9T0UCcw093259; Thu, 28 Oct 2004 17:30: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 i9T0UCAe093258; Thu, 28 Oct 2004 17:30:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0UBxN093252 for ; Thu, 28 Oct 2004 17:30:11 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9T0UOui013165 for ; Thu, 28 Oct 2004 18:30:25 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6B00C9QLEONF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 28 Oct 2004 18:30:24 -0600 (MDT) Received: from [65.38.149.48] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6B00HGCLENCR@mail.sun.net> for atom-syntax@imc.org; Thu, 28 Oct 2004 18:30:23 -0600 (MDT) Date: Thu, 28 Oct 2004 17:31:06 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: <41817FD3.7050405@intertwingly.net> To: Sam Ruby Cc: mint@franklinmint.fm, atom-syntax@imc.org, Danny Ayers Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> <11602367.1098992599478.JavaMail.dtcd@mac.com> <1f2ed5cd04102813396bad52bd@mail.gmail.com> <41815E7F.1030507@franklinmint.fm> <1f2ed5cd0410281439290575fa@mail.gmail.com> <41817FD3.7050405@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 28, 2004, at 4:25 PM, Sam Ruby wrote: > FYI: Mod speedyfeed[1] makes use of the atom:modified element. But could, and arguably should, use atom:updated -Tim From owner-atom-syntax@mail.imc.org Thu Oct 28 20:43:47 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 UAA01229 for ; Thu, 28 Oct 2004 20:43:46 -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 i9T0Zrui094244; Thu, 28 Oct 2004 17:35: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 i9T0Zrub094243; Thu, 28 Oct 2004 17:35:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40821.mail.yahoo.com (web40821.mail.yahoo.com [66.218.92.68]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T0ZnkA094207 for ; Thu, 28 Oct 2004 17:35:49 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029003558.52291.qmail@web40821.mail.yahoo.com> Received: from [131.107.76.154] by web40821.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 17:35:58 PDT Date: Thu, 28 Oct 2004 17:35:58 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > If PubSub or similar finds two copies of an entry > you made, identified by > to be the same thing, but which are different > in minor ways, how will > it know which is most recent, and thus which one to > propogate? How did PubSub find both entries? Via the same feed or on in different feeds? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 28 20:50: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 UAA02301 for ; Thu, 28 Oct 2004 20:50: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 i9T0cmlC094871; Thu, 28 Oct 2004 17:38: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 i9T0cmiO094870; Thu, 28 Oct 2004 17:38:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0cjPq094854 for ; Thu, 28 Oct 2004 17:38:45 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9T0cwNH009492 for ; Thu, 28 Oct 2004 18:38:58 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6B009HVLSXRD@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 28 Oct 2004 18:38:58 -0600 (MDT) Received: from [65.38.149.48] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6B00HQVLSVD6@mail.sun.net> for atom-syntax@imc.org; Thu, 28 Oct 2004 18:38:57 -0600 (MDT) Date: Thu, 28 Oct 2004 17:39:37 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: <0343F646-2943-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 28, 2004, at 5:00 PM, Eric Scheid wrote: >> As a publisher, I do not accept that, as a >> condition of publishing Atom, I am obligated to tell the world every >> time I make a spelling correction or trivial update. > > You already do via http Date-Modified, and if you break that you break > all > sorts of http things. How is this different? Well, I may change atom:updated on an entry even if the part of the entry that's in the feed hasn't changed. How about atom:modified? How about if I do some whitespace normalization? How about if I change the stylesheet? In a material way? In a way that's unnoticeable except for it fixes a bug in the latest Safari release? How about if I change only the serif version of the stylesheet, leaving sans-serif untouched? How about if I change the Javascript? All the stylesheet varations, on the javascript? How about if I decide to change Unicode canonicalization forms without changing the content? The notion that there is such a thing as an unambiguous change date is just silly. The virtue of atom:updated is that it's unambiguous: the publisher asserted that something is different. -Tim From owner-atom-syntax@mail.imc.org Thu Oct 28 20:55: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 UAA03346 for ; Thu, 28 Oct 2004 20:55:34 -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 i9T0kf1c096994; Thu, 28 Oct 2004 17:46: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 i9T0kewd096993; Thu, 28 Oct 2004 17:46:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0kebi096948 for ; Thu, 28 Oct 2004 17:46:40 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by wproxy.gmail.com with SMTP id 67so634691wri for ; Thu, 28 Oct 2004 17:46:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IkTKdV3XTZYaJIEKMIffn7GUaWHXMCUIeWKASG/UZqDJtosRr0BHUKIlgxpR8Hx0KjvP/lwLZbOZK4ZZ3BFyiRIvQcX5GhBRWpdBk3adz9FfthWyKcMz4g+X9xZDS5F7+pnpvCQcNdyzfr087gjavMeDYbQocJhiSAV0lnueJOY= Received: by 10.38.181.44 with SMTP id d44mr1634317rnf; Thu, 28 Oct 2004 17:46:45 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Thu, 28 Oct 2004 17:46:45 -0700 (PDT) Message-ID: <3f1451f504102817461e206be9@mail.gmail.com> Date: Thu, 28 Oct 2004 20:46:45 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: Tim Bray , Atom Syntax In-Reply-To: <418147CD.5090703@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <78DA0CDC-2914-11D9-9F4E-000A95A51C9E@sun.com> <418147CD.5090703@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 28 Oct 2004 15:26:05 -0400, Robert Sayre wrote: > -1 even if it's optional. This is protocol-level data. No it is not. This is an attribute of an entry, not the whole feed. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Oct 28 21:09: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 VAA05828 for ; Thu, 28 Oct 2004 21:09:32 -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 i9T0xVGV099747; Thu, 28 Oct 2004 17:59:31 -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 i9T0xVIF099746; Thu, 28 Oct 2004 17:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T0xUre099738 for ; Thu, 28 Oct 2004 17:59:31 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 10:59:48 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 10:59:39 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029003558.52291.qmail@web40821.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 10:35 AM, "Dare Obasanjo" wrote: >> If PubSub or similar finds two copies of an entry >> you made, identified by >> to be the same thing, but which are different >> in minor ways, how will >> it know which is most recent, and thus which one to >> propogate? > > How did PubSub find both entries? Via the same feed or > on in different feeds? how does that matter? assume different sources or mechanisms for now (ie. not in the same feed document, or the same feed source polled at different times). assume random latency in the system such that you can't be sure which is most recent simply per arrival time. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 21:30:55 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 VAA11017 for ; Thu, 28 Oct 2004 21:30:54 -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 i9T1LMDS004412; Thu, 28 Oct 2004 18:21:22 -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 i9T1LMwt004411; Thu, 28 Oct 2004 18:21:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T1LL46004405 for ; Thu, 28 Oct 2004 18:21:21 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 11:21:40 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 11:21:30 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <0343F646-2943-11D9-9F4E-000A95A51C9E@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 10:39 AM, "Tim Bray" wrote: > Well, I may change atom:updated on an entry even if the part of the > entry that's in the feed hasn't changed. That's ok. atom:updated is more an editorial thing than a mechanics thing. (I hadn't realised until now that's a possible use case though. Interesting) > How about atom:modified? How > about if I do some whitespace normalization? hmm .. the pace at some point was meant to state that changes due simply to XML re-serialisation shouldn't be signalled by atom:modified ... currently it only implies that. > How about if I change the stylesheet? In a material way? In a way that's > unnoticeable except for it fixes a bug in the latest Safari release? How > about if I change only the serif version of the stylesheet, leaving sans-serif > untouched? Is the stylesheet content actually in the atom entry, or is it referenced from there? If it's external, then it has it's own http:last-modified value. > How about if I change the Javascript? All the stylesheet varations, > on the javascript? Is the javascript content actually in the atom entry, or is it referenced from there? If it's external, then it has it's own http:last-modified value. > How about if I decide to change Unicode > canonicalization forms without changing the content? Is this an XML serialisation change? atom:modified shouldn't be incremented for that, same as it shouldn't be incremented if you simply change the order of the entry elements (since order is not significant). Similarly atom:modified shouldn't be incremented if is re-serialised as . I hope I'm making this point clear. I hope this point is something which can be clear, or are there all sorts of messy edge cases where something could be re-serialisation or it could be content change? (please don't mention QNames) The pace currently says: Publishers SHOULD NOT change the value of atom:modified when no changes in the entry have occurred (eg. when re-serialising or re-exporting the entry). that was written with the thought that "entry" is the conceptual thing, not the particular xml serialisation. That is, if the data inputs are the same, regardless of the xml-serialisation outputs. The wording can be improved, I can see that. Suggestions? e. From owner-atom-syntax@mail.imc.org Thu Oct 28 21:30:57 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 VAA11044 for ; Thu, 28 Oct 2004 21:30:57 -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 i9T1LaQl004435; Thu, 28 Oct 2004 18:21:36 -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 i9T1LabE004434; Thu, 28 Oct 2004 18:21:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T1LYqA004428 for ; Thu, 28 Oct 2004 18:21:35 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 11:21:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 11:21:45 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041028215428.96072.qmail@web40809.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 7:54 AM, "Dare Obasanjo" wrote: >> Where should you look for 'Last-Modified' >> information when you can't get >> it from HTTP? > > The real question is why you'd be looking for "last > modified" information from an entry in the first place > when atom:updated exists. Why? When you two versions of the same entry, and they both have the same atom:updated value, yet they are different in content. How do you determine which is the most recently modified? e. From owner-atom-syntax@mail.imc.org Thu Oct 28 21:35: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 VAA12063 for ; Thu, 28 Oct 2004 21:35: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 i9T1PrBm005400; Thu, 28 Oct 2004 18:25: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 i9T1PrvT005399; Thu, 28 Oct 2004 18:25:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40810.mail.yahoo.com (web40810.mail.yahoo.com [66.218.78.187]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T1Pr30005362 for ; Thu, 28 Oct 2004 18:25:53 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029012602.11845.qmail@web40810.mail.yahoo.com> Received: from [131.107.71.94] by web40810.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 18:26:02 PDT Date: Thu, 28 Oct 2004 18:26:02 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > how does that matter? The PubSub folks have said they don't plan to consider entries with the same ID in different feeds as the same due to spoofing. So that would throw out one of the cases in your question. If they were in the same feed then the content from the most recent time the feed was fetched can be used. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 28 21:38:28 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 VAA12907 for ; Thu, 28 Oct 2004 21:38:27 -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 i9T1TVPS006141; Thu, 28 Oct 2004 18:29:31 -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 i9T1TViq006140; Thu, 28 Oct 2004 18:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T1TU4g006133 for ; Thu, 28 Oct 2004 18:29:31 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 11:29:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 11:29:40 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041028220402.97498.qmail@web40809.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 8:04 AM, "Dare Obasanjo" wrote: >> "...a model like NetNewsWire that shows the >> differences using an HTML diff." I use NNW, and the HTML diff is good ... when it works! When it doesn't work, it's just a bunch of noise. It doesn't always fail gracefully, imho. > Exactly. If I was going to have some way of showing > users each minute change that occured to an entry then > I'd simply run a diff between old and new each time I > fetched the entry not test against some optional or > mandatory last-modified element then "alert" the user. oh great. one of my complaints about NNW's html diff is that if a publisher tweaks their publishing system which cause certain changes in the XML serialisation, then every darn entry in their feed is marked as "modified". Very tedious to go through that mess of noise. By the way, Brent Simmons (of NNW fame) is in favour of a date-modified element, last I heard. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 21:43: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 VAA14040 for ; Thu, 28 Oct 2004 21:43: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 i9T1XrVg007020; Thu, 28 Oct 2004 18:33: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 i9T1XrQG007018; Thu, 28 Oct 2004 18:33:53 -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 i9T1XoJR006993 for ; Thu, 28 Oct 2004 18:33:52 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNLeR-0003kA-7e; Fri, 29 Oct 2004 01:33:59 +0000 Message-ID: <41819E02.5040404@franklinmint.fm> Date: Thu, 28 Oct 2004 21:33:54 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > > Why? When you two versions of the same entry, and they both have the same > atom:updated value, yet they are different in content. How do you determine > which is the most recently modified? The definition of atom:updated holds the answer to that question--it doesn't matter. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 28 21:45:38 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 VAA14371 for ; Thu, 28 Oct 2004 21:45:37 -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 i9T1dOXS008381; Thu, 28 Oct 2004 18:39: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 i9T1dOdL008380; Thu, 28 Oct 2004 18:39:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T1dMR3008363 for ; Thu, 28 Oct 2004 18:39:23 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 11:39:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 11:39:32 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029012602.11845.qmail@web40810.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 11:26 AM, "Dare Obasanjo" wrote: > The PubSub folks have said they don't plan to consider > entries with the same ID in different feeds as the > same due to spoofing. So that would throw out one of > the cases in your question. Only if you restrict the case to pubsub with that policy in place. The case remains for other sources, and may even remain for pubsub if the entries were signed. > If they were in the same feed then the content from the most recent time the > feed was fetched can be used. (assuming they don't have multiple bots doing the low level polling work and feeding that into their system - do they now note the polling time, or the input into the system time?) how about two feeds from the same publisher (eg. a main feed and a category feed)? and it's not just Pubsub to consider. Even desktop aggregators might need to do this kind of thing... it might be receiving some entries via XMPP, and others by polling, some direct from the source, some via some intermediary filtering service, some might get routed via a proxy, some might not. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 21:46: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 VAA14542 for ; Thu, 28 Oct 2004 21:46: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 i9T1cEkw008129; Thu, 28 Oct 2004 18:38:14 -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 i9T1cExR008128; Thu, 28 Oct 2004 18:38:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40812.mail.yahoo.com (web40812.mail.yahoo.com [66.218.78.189]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T1cDfF008100 for ; Thu, 28 Oct 2004 18:38:13 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029013822.63409.qmail@web40812.mail.yahoo.com> Received: from [131.107.71.227] by web40812.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 18:38:22 PDT Date: Thu, 28 Oct 2004 18:38:22 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > > The real question is why you'd be looking for > "last > > modified" information from an entry in the first > place > > when atom:updated exists. > > Why? When you two versions of the same entry, and > they both have the same > atom:updated value, yet they are different in > content. How do you determine > which is the most recently modified? The one you fetched most recently from the feed. Is this a trick question? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Thu Oct 28 21:54:28 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 VAA17485 for ; Thu, 28 Oct 2004 21:54:27 -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 i9T1jGvp008954; Thu, 28 Oct 2004 18:45: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 i9T1jG5C008953; Thu, 28 Oct 2004 18:45:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T1jFT9008947 for ; Thu, 28 Oct 2004 18:45:15 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 11:45:34 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 11:45:25 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029013822.63409.qmail@web40812.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 11:38 AM, "Dare Obasanjo" wrote: >> How do you determine >> which is the most recently modified? > > The one you fetched most recently from the feed. that's not a good assumption to make as to which is most recently modified. lots of things can go wrong to break that assumption. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 22:00:47 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 WAA19398 for ; Thu, 28 Oct 2004 22:00:46 -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 i9T1qLZQ009581; Thu, 28 Oct 2004 18:52: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 i9T1qLO6009580; Thu, 28 Oct 2004 18:52:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T1qKpn009565 for ; Thu, 28 Oct 2004 18:52:21 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 11:52:39 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 11:52:30 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41819E02.5040404@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 11:33 AM, "Robert Sayre" wrote: >> Why? When you two versions of the same entry, and they both have the same >> atom:updated value, yet they are different in content. How do you determine >> which is the most recently modified? > > The definition of atom:updated holds the answer to that question--it > doesn't matter. then why would anyone even bother fixing spelling errors in their entries? it does matter, it just doesn't need shouting from the rooftops, or if it does you use atom:updated which is expressly for that purpose: [...] which the publisher wishes to bring to the attention of subscribers [...] Consider other variations of modified entries, not just spelling fixes ... say I have the capability to include various bits of meta-data in my entries, and I do so because I consider that to be of value. I don't always have the meta-data to immediately to hand (eg. some has to wait until I get back to the office). I make those changes. It's not screamingly important that readers are alerted to this augmentation, but it's still useful to those that look for it. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 22:12:23 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 WAA21782 for ; Thu, 28 Oct 2004 22:12:23 -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 i9T25JbB011869; Thu, 28 Oct 2004 19:05: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 i9T25JLS011868; Thu, 28 Oct 2004 19:05:19 -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 i9T25IYa011860 for ; Thu, 28 Oct 2004 19:05:18 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNM8v-0000Zb-E8; Fri, 29 Oct 2004 02:05:31 +0000 Message-ID: <4181A55B.1040405@franklinmint.fm> Date: Thu, 28 Oct 2004 22:05:15 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 29/10/04 11:33 AM, "Robert Sayre" wrote: > >>The definition of atom:updated holds the answer to that question--it >>doesn't matter. > > > then why would anyone even bother fixing spelling errors in their entries? > > it does matter, it just doesn't need shouting from the rooftops, or if it > does you use atom:updated which is expressly for that purpose: > > [...] which the publisher wishes to bring > to the attention of subscribers [...] If the definition of atom:updated depends on atom:modified for its semantics, the two dates should have been proposed together. I would say there is no such dependency, and the idea of storing a modification date in the document itself is silly. In particular, editing an atom:entry in a text editor but forgetting to update atom:modified results in a non-compliant Atom Document. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Oct 28 22:13: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 WAA22010 for ; Thu, 28 Oct 2004 22:13: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 i9T26qHv012147; Thu, 28 Oct 2004 19:06: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 i9T26q26012146; Thu, 28 Oct 2004 19:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40829.mail.yahoo.com (web40829.mail.yahoo.com [66.218.92.76]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9T26pVt012130 for ; Thu, 28 Oct 2004 19:06:51 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029020700.35332.qmail@web40829.mail.yahoo.com> Received: from [131.107.76.30] by web40829.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 19:07:00 PDT Date: Thu, 28 Oct 2004 19:07:00 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > On 29/10/04 11:38 AM, "Dare Obasanjo" > wrote: > > >> How do you determine > >> which is the most recently modified? > > > > The one you fetched most recently from the feed. > > that's not a good assumption to make as to which is > most recently modified. > lots of things can go wrong to break that > assumption. Like what? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Thu Oct 28 22:40: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 WAA25661 for ; Thu, 28 Oct 2004 22:40: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 i9T2VGSR015950; Thu, 28 Oct 2004 19:31: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 i9T2VGQq015949; Thu, 28 Oct 2004 19:31:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T2VG48015942 for ; Thu, 28 Oct 2004 19:31:16 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9T2VOq1012449; Thu, 28 Oct 2004 22:31:24 -0400 (EDT) Received: from BobT41 (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWP02800 (AUTH bob@wyman.us); Thu, 28 Oct 2004 22:31:23 -0400 (EDT) Message-Id: <200410290231.BWP02800@ms8.netsolmail.com> From: "Bob Wyman" To: "'Sam Ruby'" , "'Danny Ayers'" Cc: , Subject: RE: PaceDateModified Date: Thu, 28 Oct 2004 22:31:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS9SR2Y+2Ne+nTZRDmY8hBYQPmXTQAE6TXw In-Reply-To: <41817FD3.7050405@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: >FYI: Mod speedyfeed[1] makes use of the atom:modified element. I think that in general, most implementations of RFC3229+feed[2] would also want to atom:modified available to them. A developer of the delta-generating code would be seeking to determine, as accurately and efficiently as possible, what changes have occurred in a feed since some particular point in time. Developers would probably prefer to be able to rely on atom:modified, in the manner that mod_speedyfeed does, in order to avoid having to do the more-expensive byte-oriented diffs which would be needed to determine which entries have been modified. Without something like atom:modified, RFC3229+feed implementors might end up relying on atom:updated, which would result in some modifications never being published to at least some readers of the feed. One other alternative might be to maintain a database of MD5 hashes that it could use to recognize changes. Yet another alternative would be for feed generating software to insert "temporary" atom:modified that would be filtered when generating the "real" or delta feed. Most of the alternatives to having atom:modified are pretty ugly. Given that RFC3229+feed can result in very large bandwidth savings[3] and appears to be gaining reasonable deployment, it might make sense to support atom:modified to facilitate the generation of delta feeds. It should also be noted that atom:modified would potentially make duplicate checking easier for intermediary filtering services like PubSub, or for multi-feed database applications like the search engines delivered by Feedster, Technorati, BlogPulse, etc. bob wyman [1] http://asdf.blogs.com/asdf/2004/09/mod_speedyfeed__1.html [2] http://bobwyman.pubsub.com/main/2004/09/implementations.html [3] At PubSub.com, our average byte/request for all requests that return feeds (i.e. not 302 responses or errors) has been reduced to 28% of what it was before we implemented RFC3229+feed in our servers. As more clients support delta-feeds, the savings will increase even more. From owner-atom-syntax@mail.imc.org Thu Oct 28 23:00:26 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 XAA29324 for ; Thu, 28 Oct 2004 23:00:26 -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 i9T2sgd1017850; Thu, 28 Oct 2004 19:54: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 i9T2sggL017849; Thu, 28 Oct 2004 19:54:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T2sfoo017843 for ; Thu, 28 Oct 2004 19:54:41 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 12:54:05 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 12:53:56 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029020700.35332.qmail@web40829.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 12:07 PM, "Dare Obasanjo" wrote: >>>> How do you determine >>>> which is the most recently modified? >>> >>> The one you fetched most recently from the feed. >> >> that's not a good assumption to make as to which is >> most recently modified. >> lots of things can go wrong to break that >> assumption. > > Like what? I'm writing this from my laptop, connected via wifi. Sometimes I connect via an ethernet cable instead (much faster!). Those two connections use different routes, one of them might have a proxy in place, one might not. I also visit clients where I can connect to the internet via their corporate connection. At least one is a huge multinational networking mob, whose Sydney, Australia office is routed via some place in the USA, not via the domestic ISP network. Thus I sometimes appear to be someplace geographically quite different, based on the IP address I happen to use. Some publishers have geographically dispersed web servers, and have different publishing schedules, or at least delays as they push the bits around the world. Add proxies to the mix. Add round-robin web farms to the mix. Pray nothing breaks. It is thus quite possible that I retrieve the most recently updated feed in one moment, and then a short time later retrieve an older version from the same URI. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 23:00:50 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 XAA29426 for ; Thu, 28 Oct 2004 23:00:50 -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 i9T2rgLu017750; Thu, 28 Oct 2004 19:53: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 i9T2rgSh017749; Thu, 28 Oct 2004 19:53:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T2rflm017742 for ; Thu, 28 Oct 2004 19:53:41 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9T2rslF005786; Thu, 28 Oct 2004 22:53:54 -0400 (EDT) Received: from BobT41 (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWP06155 (AUTH bob@wyman.us); Thu, 28 Oct 2004 22:53:53 -0400 (EDT) Message-Id: <200410290253.BWP06155@ms8.netsolmail.com> From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: PaceDateModified Date: Thu, 28 Oct 2004 22:53:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS9TOMwJsAr1f0tTXu8CUWJQR19+QAEr1Sw In-Reply-To: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > If PubSub or similar finds two copies of an entry you made, > identified by to be the same thing, but which are different > in minor ways, how will it know which is most recent, and thus > which one to propogate? Other intermediaries might make different choices, but I'm afraid that what we at PubSub would probably send both copies of the entry. We'd have to do this since in many cases we would have no idea which was the more recent entry. On the other hand, if atom:modified was supported and required, we might be able to stop doing many of the heuristics we currently do and rely on the publisher to tell us - via atom:modified - which is the most recent version of an entry. In general, I prefer any solution that empowers the publisher, rather than an in-channel intermediary (even one I'm building), to make authoritative statements about messages and message sequences. bob wyman From owner-atom-syntax@mail.imc.org Thu Oct 28 23:07:28 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 XAA00431 for ; Thu, 28 Oct 2004 23:07:27 -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 i9T31qjc018559; Thu, 28 Oct 2004 20:01: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 i9T31qZd018558; Thu, 28 Oct 2004 20:01:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T31opP018522 for ; Thu, 28 Oct 2004 20:01:51 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 13:01:39 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 13:01:30 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4181A55B.1040405@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 12:05 PM, "Robert Sayre" wrote: > If the definition of atom:updated depends on atom:modified for its semantics, > the two dates should have been proposed together. > a moot point since it was mandated that all date elements be proposed singly, one at a time. > I would say there is no such dependency, and the idea of storing a > modification date in the document itself is silly. I agree there is no dependency. On the second part, by extension the idea of storing a modification date in the CMS database is also silly. Or is it? Is the meta-data of date-modified important or useful to the publisher? > In particular, editing an atom:entry in a text editor but forgetting to update > atom:modified results in a non-compliant Atom Document. by the same argument we shouldn't be asking for xml well-formedness either, since that can be screwed up with manual editing. Not convinced. e. From owner-atom-syntax@mail.imc.org Thu Oct 28 23:23:59 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 XAA02354 for ; Thu, 28 Oct 2004 23:23:58 -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 i9T38hBb019332; Thu, 28 Oct 2004 20:08:43 -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 i9T38hIY019331; Thu, 28 Oct 2004 20:08:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T38hoV019325 for ; Thu, 28 Oct 2004 20:08:43 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9T38uoq024729; Thu, 28 Oct 2004 23:08:56 -0400 (EDT) Received: from BobT41 (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWP08210 (AUTH bob@wyman.us); Thu, 28 Oct 2004 23:08:55 -0400 (EDT) Message-Id: <200410290308.BWP08210@ms8.netsolmail.com> From: "Bob Wyman" To: "'Dare Obasanjo'" , "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: PaceDateModified Date: Thu, 28 Oct 2004 23:08:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS9WGtoNiTiL3swSCePdo8wqhScowACq0aQ In-Reply-To: <20041029012602.11845.qmail@web40810.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > The PubSub folks have said they don't plan to consider > entries with the same ID in different feeds as the > same due to spoofing. So that would throw out one of > the cases in your question. I don't think this is a fair characterization of my position on the subject. Certainly, I have pointed out a number of problems with trusting atom:id across feeds. However, there *are* situations in which we would be able to use such trust. For instance, we might know of specific sets of feeds that were known to be under stable and responsible management (perhaps a cluster of "main feed" plus category feeds) or at some time in the future we might get a mechanism to generate digital signatures. It should also be recognized that in some cases, we'll be consuming "aggregate" feeds without knowing it. In any of these cases (and perhaps others) we might, in fact, chose or be forced to support cross-feed atom:ids. So, while Dare is correct that I have many concerns about cross-feed atom:ids, these concerns are *not* universal and won't exist in all cases. It would be good, I think, to design features such as atom:modified as though cross-feed atom:ids *were* trust-worthy in order to ensure that we don't block paths to implementing truley trust-worthy id systems in the future. bob wyman From owner-atom-syntax@mail.imc.org Thu Oct 28 23:39:48 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 XAA03797 for ; Thu, 28 Oct 2004 23:39:48 -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 i9T3P7Jb023044; Thu, 28 Oct 2004 20:25:07 -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 i9T3P7Bk023043; Thu, 28 Oct 2004 20:25:07 -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 i9T3P6JI023027 for ; Thu, 28 Oct 2004 20:25:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=franklinmint.fm) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNNO9-0005Ed-3C; Fri, 29 Oct 2004 03:25:17 +0000 Message-ID: <4181E1BF.4070500@franklinmint.fm> Date: Thu, 28 Oct 2004 23:22:55 -0700 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 29/10/04 12:05 PM, "Robert Sayre" wrote: > > >>In particular, editing an atom:entry in a text editor but forgetting to update >>atom:modified results in a non-compliant Atom Document. >> >> > >by the same argument we shouldn't be asking for xml well-formedness either, >since that can be screwed up with manual editing. Not convinced. > > No, it's not the same argument. A well-formedness error would result in an invalid document, whereas the situation I described would not. There are lots of reasons last-modified timestamps are stored outside a given piece of data, in stuff like file systems, http, etc. I suppose we can work through each and every reason for this state of affairs, and why we've worked out something better. I don't buy any of the mod_speedyfeed arguments, btw. If you can install such a module, you'd do better to point it at a directory of entries and work from the files' timestamps, as opposed to firing up an XML parser and dissecting a feed. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 01:55: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 BAA11865 for ; Fri, 29 Oct 2004 01:55: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 i9T5hYFJ047852; Thu, 28 Oct 2004 22:43: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 i9T5hYi8047851; Thu, 28 Oct 2004 22:43: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 i9T5hVoJ047786 for ; Thu, 28 Oct 2004 22:43:32 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 92B4A7C2E9; Fri, 29 Oct 2004 07:39:52 +0200 (CEST) Date: Fri, 29 Oct 2004 07:45:08 +0200 To: "Robert Sayre" , "Eric Scheid" Subject: Re: PaceDateModified Cc: "Atom Syntax" References: <4181E1BF.4070500@franklinmint.fm> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4181E1BF.4070500@franklinmint.fm> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 28 Oct 2004 23:22:55 -0700, Robert Sayre wrote: > There are lots of reasons last-modified timestamps are stored outside a > given piece of data, in stuff like file systems, http, etc. Yet again: Not for (all) entries. Most entries doesn't live outside the feed, and thus is never transported singularly over HTTP and thus hasn't got any 'Last-Modified' HTTP header attached to them at any time in their lifecycle. -- 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 Fri Oct 29 06:10: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 GAA14315 for ; Fri, 29 Oct 2004 06:10: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 i9TA0k5l099425; Fri, 29 Oct 2004 03:00: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 i9TA0k4r099424; Fri, 29 Oct 2004 03:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TA0jVK099417 for ; Fri, 29 Oct 2004 03:00:46 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so54445rnk for ; Fri, 29 Oct 2004 03:00:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GWYxZVyTRR5nNLG7i5VIsFF7gRLnDxeSAJFVQ6D+jKouWrUG6bQbgMeJeSFLvhXl1HWAinmxUhg5pq5XYze7h6zuqhfYhAwGdzDLkH441XC9P3FCkptzFHFg2se5dR8PFgEkjdOutE2llRrC+poeOHgGvoUVAf5ibIi9Cpn8Ves= Received: by 10.38.8.65 with SMTP id 65mr129584rnh; Fri, 29 Oct 2004 03:00:38 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 03:00:38 -0700 (PDT) Message-ID: <1f2ed5cd041029030079781412@mail.gmail.com> Date: Fri, 29 Oct 2004 12:00:38 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: Re: PaceDateModified Cc: norman.walsh@Sun.COM, kpako@yahoo.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4181E1BF.4070500@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ok, Dare mentioned that RSS Bandit and some other aggregators use internal heuristics to determine what has changed in a feed and what should be presented to the user. This is fine assuming entries come from a single source. But how does, and how *should* these tools behave in the following *real* scenario: I am subscribed to the folllowing feeds: http://planetrdf.com/index.rdf http://planet.xmlhack.com/index.rdf http://rss.pubsub.com/37/b5/3778cec38f25c9f8282681622a.xml The first is Planet XMLhack, the second Planet RDF. The third is a PubSub subscription. Whenever Norm Walsh posts to his blog, the items are picked up on the first two feeds. If he happens to mention "environment-friendly lawn mowers" it will be picked up on the third as well. So my aggregator will receive three copies of the same item. Now assume all these systems are using Atom. Norm corrects a spelling mistake. My aggregator receives two copies of the entry prior to the correction, one after. They all have the same atom:updated value, as it was only a minor change. How does my aggregator know which version of the entry to display? Note that I'm not even subscribed to Norm's original feed, so Dare's feed-refresh based heuristics are dead in the water. I'm not going to lie in the road for anything, I just think Atom will be hobbled as the syndication environment gets more distributed without atom:modified (or equivalent). If doesn't go into Atom 1.0, I can assure you it will be in the next version, after the issues have stacked up. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 06:13: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 GAA14405 for ; Fri, 29 Oct 2004 06:13:34 -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 i9T9ux1h098550; Fri, 29 Oct 2004 02:56:59 -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 i9T9uxF3098548; Fri, 29 Oct 2004 02:56:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T9uw6r098481 for ; Fri, 29 Oct 2004 02:56:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9T9W3fW007190; Fri, 29 Oct 2004 10:32:06 +0100 (BST) Message-ID: <41820E14.5000005@mac.com> Date: Fri, 29 Oct 2004 10:32:04 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >I'm writing this from my laptop, connected via wifi. Sometimes I connect via >an ethernet cable instead (much faster!). Those two connections use >different routes, one of them might have a proxy in place, one might not. I >also visit clients where I can connect to the internet via their corporate >connection. At least one is a huge multinational networking mob, whose >Sydney, Australia office is routed via some place in the USA, not via the >domestic ISP network. Thus I sometimes appear to be someplace geographically >quite different, based on the IP address I happen to use. Some publishers >have geographically dispersed web servers, and have different publishing >schedules, or at least delays as they push the bits around the world. Add >proxies to the mix. Add round-robin web farms to the mix. Pray nothing >breaks. > >It is thus quite possible that I retrieve the most recently updated feed in >one moment, and then a short time later retrieve an older version from the >same URI. > You know, you could have saved everybody's time by abbreviating that to "I've lost the argument". Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 06:44:50 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 GAA16345 for ; Fri, 29 Oct 2004 06:44:50 -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 i9TAbTsV006822; Fri, 29 Oct 2004 03:37:29 -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 i9TAbTpk006821; Fri, 29 Oct 2004 03:37:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TAbS6w006802 for ; Fri, 29 Oct 2004 03:37:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TADksn028221; Fri, 29 Oct 2004 11:13:46 +0100 (BST) Message-ID: <418217DB.9040207@mac.com> Date: Fri, 29 Oct 2004 11:13:47 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: atom-syntax@imc.org, kpako@yahoo.com Subject: Re: PaceDateModified References: <4181E1BF.4070500@franklinmint.fm> <1f2ed5cd041029030079781412@mail.gmail.com> In-Reply-To: <1f2ed5cd041029030079781412@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: >How does my aggregator know which version of the entry to display? > That depends entirely on the UI of your aggregator. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 06:45: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 GAA16374 for ; Fri, 29 Oct 2004 06:45: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 i9TAaYWM006643; Fri, 29 Oct 2004 03:36: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 i9TAaYNf006642; Fri, 29 Oct 2004 03:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TAaXuJ006554 for ; Fri, 29 Oct 2004 03:36:34 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 20:36:08 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 20:36:02 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41820E14.5000005@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 7:32 PM, "Graham Parks" wrote: > You know, you could have saved everybody's time by abbreviating that to > "I've lost the argument". Your logic is broken. Dare asked how it is possible, I gave multiple examples of just how. If you'd rather just hand wave at the assumptions, just say so. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 08:21:20 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 IAA23309 for ; Fri, 29 Oct 2004 08:21:19 -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 i9TC9tqF022753; Fri, 29 Oct 2004 05:09: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 i9TC9su1022752; Fri, 29 Oct 2004 05:09:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TC9riq022669 for ; Fri, 29 Oct 2004 05:09:53 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TBmC2Y018699; Fri, 29 Oct 2004 12:48:13 +0100 (BST) Message-ID: <41822DFE.6040400@mac.com> Date: Fri, 29 Oct 2004 12:48:14 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid , Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric, you're trying to argue that the most recent version of a resource is not the most recent version of a resource. Even if the conditions you describe prevail, there is absolutely nothing wrong with an aggregator that displays the most recent version of a resource as the most recent version of that resource. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 08:22: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 IAA23450 for ; Fri, 29 Oct 2004 08:22: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 i9TC9ALY022448; Fri, 29 Oct 2004 05:09:10 -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 i9TC9AqV022447; Fri, 29 Oct 2004 05:09:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TC99sY022439 for ; Fri, 29 Oct 2004 05:09:09 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so65423rnb for ; Fri, 29 Oct 2004 05:09:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EmUk2agz/R+7RfHIKrPrjfa5V3YS37uP4Yy7jJoPFDSKVCkzlTrcQlJURmdgj+IPrEgcsMkot0WG3Hrpz2aJhEBGIcNEFKaT30qX+nONPxvsu5w0R/GSL2BJhYK1V9uiHmayqJgfYgYWfqQgrXGavzkImNJDwVRPy/lyOsapVMU= Received: by 10.38.98.30 with SMTP id v30mr213881rnb; Fri, 29 Oct 2004 05:09:05 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 05:09:05 -0700 (PDT) Message-ID: <1f2ed5cd04102905097aa3219@mail.gmail.com> Date: Fri, 29 Oct 2004 14:09:05 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Parks Subject: Re: PaceDateModified Cc: atom-syntax@imc.org, kpako@yahoo.com In-Reply-To: <418217DB.9040207@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4181E1BF.4070500@franklinmint.fm> <1f2ed5cd041029030079781412@mail.gmail.com> <418217DB.9040207@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 11:13:47 +0100, Graham Parks wrote: > Danny Ayers wrote: > > >How does my aggregator know which version of the entry to display? > > > That depends entirely on the UI of your aggregator. Ok. Put it another way: My aggregator database contains 3 entries with have the same values for atom:id and atom:updated. They came from three different source feeds, as described earlier. Two of these have spelling mistakes in the content. The third was produced later, and the mistake has been corrected. How does my aggregator select the latest (corrected) version from my database? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 08:34: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 IAA24168 for ; Fri, 29 Oct 2004 08:34: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 i9TCS0fK027379; Fri, 29 Oct 2004 05:28:00 -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 i9TCS0eJ027378; Fri, 29 Oct 2004 05:28:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCRxDp027366 for ; Fri, 29 Oct 2004 05:28:00 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 22:28:06 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 22:26:45 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41822DFE.6040400@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 9:48 PM, "Graham Parks" wrote: > Eric, you're trying to argue that the most recent version of a resource > is not the most recent version of a resource. I'm doing nothing of the kind. Please go back and re-read the email ... I'm arguing that the most recently *retrieved* version is not necessarily the most recently *modified* version, particularly so when we're talking about specific published instances of those resources. retrieved vs modified. two different things. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 08:34:28 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 IAA24193 for ; Fri, 29 Oct 2004 08:34:28 -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 i9TCRb07027305; Fri, 29 Oct 2004 05:27:37 -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 i9TCRbAx027304; Fri, 29 Oct 2004 05:27:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40825.mail.yahoo.com (web40825.mail.yahoo.com [66.218.92.72]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TCRbNl027276 for ; Fri, 29 Oct 2004 05:27:37 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029122728.96505.qmail@web40825.mail.yahoo.com> Received: from [24.18.132.123] by web40825.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 05:27:28 PDT Date: Fri, 29 Oct 2004 05:27:28 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > then why would anyone even bother fixing spelling > errors in their entries? Why do you keep pretending that atom:updated does not exist? If I fix a typo in my feed, I can update the atom:updated value if I feel it is that important that people pick up the change. Even better my CMS/blogging tool can do it automagically. > it does matter, it just doesn't need shouting from > the rooftops, or if it > does you use atom:updated which is expressly for > that purpose: > > [...] which the publisher wishes to bring > to the attention of subscribers [...] > > Consider other variations of modified entries, not > just spelling fixes ... > say I have the capability to include various bits of > meta-data in my > entries, and I do so because I consider that to be > of value. I don't always > have the meta-data to immediately to hand (eg. some > has to wait until I get > back to the office). I make those changes. It's not > screamingly important > that readers are alerted to this augmentation, but > it's still useful to > those that look for it. I can't support having both atom:updated & atom:modified in the Atom syndication format. The amount of confusion caused by having both elements will not be worth the few edge cases that you and Danny Ayers are trumpeting as being helped by having both elements. -1 PaceDateModified It is extremely unlikely that anything anyone else will say in this thread will convince me otherwise. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 29 08:49:58 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 IAA25456 for ; Fri, 29 Oct 2004 08:49:58 -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 i9TCiKiB031015; Fri, 29 Oct 2004 05:44: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 i9TCiKhi031014; Fri, 29 Oct 2004 05:44:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCiJuD030967 for ; Fri, 29 Oct 2004 05:44:20 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TCIDbi003289; Fri, 29 Oct 2004 13:18:13 +0100 (BST) Message-ID: <41823505.4020106@mac.com> Date: Fri, 29 Oct 2004 13:18:13 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: atom-syntax@imc.org Subject: Re: PaceDateModified References: <4181E1BF.4070500@franklinmint.fm> <1f2ed5cd041029030079781412@mail.gmail.com> <418217DB.9040207@mac.com> <1f2ed5cd04102905097aa3219@mail.gmail.com> In-Reply-To: <1f2ed5cd04102905097aa3219@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: >My aggregator database contains 3 entries with have the same values >for atom:id and atom:updated. They came from three different source >feeds, as described earlier. Two of these have spelling mistakes in >the content. The third was produced later, and the mistake has been >corrected. > >How does my aggregator select the latest (corrected) version from my database? > Depends what you clicked on to get to it. If you clicked on a specific feed to get to the entry, then obviousdly it would show the entry from that feed. So I guess we're talking about an aggregated list of entries (something I personally never use). The aggregator would then need to have functionality that removed duplicates, based on id. Because of the dangers of spoofing I'd imagine this would be off by default. At that point, yes, a modified date would be useful. But it would be part of special functionality that removed duplicates, and not part of basic display functionality, as you're question sets it up to be. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 08:52: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 IAA25683 for ; Fri, 29 Oct 2004 08:52: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 i9TCiuVw031299; Fri, 29 Oct 2004 05:44: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 i9TCiulU031298; Fri, 29 Oct 2004 05:44:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40802.mail.yahoo.com (web40802.mail.yahoo.com [66.218.78.179]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TCiukr031285 for ; Fri, 29 Oct 2004 05:44:56 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029124447.14794.qmail@web40802.mail.yahoo.com> Received: from [24.18.132.123] by web40802.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 05:44:47 PDT Date: Fri, 29 Oct 2004 05:44:47 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Danny Ayers , atom-syntax@imc.org Cc: norman.walsh@Sun.COM, kpako@yahoo.com In-Reply-To: <1f2ed5cd041029030079781412@mail.gmail.com> 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: --- Danny Ayers wrote: > > I am subscribed to the folllowing feeds: > > http://planetrdf.com/index.rdf > http://planet.xmlhack.com/index.rdf > http://rss.pubsub.com/37/b5/3778cec38f25c9f8282681622a.xml > > The first is Planet XMLhack, the second Planet RDF. > The third is a > PubSub subscription. > > Whenever Norm Walsh posts to his blog, the items are > picked up on the > first two feeds. If he happens to mention > "environment-friendly lawn > mowers" it will be picked up on the third as well. > So my aggregator > will receive three copies of the same item. > > Now assume all these systems are using Atom. Norm > corrects a spelling > mistake. My aggregator receives two copies of the > entry prior to the > correction, one after. They all have the same > atom:updated value, as > it was only a minor change. > > How does my aggregator know which version of the > entry to display? First of all this assumes the aggregator tracks items across different feeds with the same ID. So far I haven't seen an aggregator that does this, I could do this in RSS Bandit but don't due to the high cost of tracking this memory/perf wise. More importantly, your scenario assumes that all 3 feeds are republishing the atom:modified date from Norm's feed which in many cases may not be true. What if PlanetXMLHack upgrades their server software which fixes some transcription errors that have occured in how they emit feeds (I believe Sam pointed some issues out in his blog) won't they change atom:modified? What if this atom:modified date for the now correctly transcribed entry is later than the typo fixed entry in Norm's feed? If the aggregator blindly accepted atom:modified across feeds then it would replace the typo fixed entry with the entry still containing the typo because one of the Planet* feeds changed some of their feed generating code. Using atom:modified in this scenario is a hack that will most likely break down more often than it would work. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 29 08:55:13 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 IAA25914 for ; Fri, 29 Oct 2004 08:55:12 -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 i9TCiT2n031037; Fri, 29 Oct 2004 05:44:29 -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 i9TCiTAE031036; Fri, 29 Oct 2004 05:44:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCiRNX031024 for ; Fri, 29 Oct 2004 05:44:28 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 29 Oct 2004 22:44:34 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 29 Oct 2004 22:44:28 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029122728.96505.qmail@web40825.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 10:27 PM, "Dare Obasanjo" wrote: >> then why would anyone even bother fixing spelling >> errors in their entries? > > Why do you keep pretending that atom:updated does not > exist? I don't, so please don't mis-characterise my position as such. If the change, even a spelling fix, is significant, then yes, increment atom:updated. That's what its there for. However, if the change isn't significant *enough* to bring to the attention of subscribers who might have already seen the entry, but still important enough to fix the public record, then what ... ? Without atom:modified, such changes might well never propagate through systems, even if more recently retrieved. I've got at least one system elsewhere where propagation is optimised to ignore those things which have apparently not been modified. Saves bandwidth, saves CPU, saves time, saves resources. I won't be able to do the same optimisations with Atom if I don't have atom:modified. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 09:20: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 JAA27504 for ; Fri, 29 Oct 2004 09:20: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 i9TDAUSS036330; Fri, 29 Oct 2004 06:10:30 -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 i9TDAUrK036329; Fri, 29 Oct 2004 06:10:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40803.mail.yahoo.com (web40803.mail.yahoo.com [66.218.78.180]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TDATV4036290 for ; Fri, 29 Oct 2004 06:10:29 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029131026.72619.qmail@web40803.mail.yahoo.com> Received: from [24.18.132.123] by web40803.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 06:10:26 PDT Date: Fri, 29 Oct 2004 06:10:26 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Eric Scheid , Atom Syntax In-Reply-To: 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: --- Eric Scheid wrote: > > I don't, so please don't mis-characterise my > position as such. > > If the change, even a spelling fix, is significant, > then yes, increment > atom:updated. That's what its there for. > > However, if the change isn't significant *enough* to > bring to the attention > of subscribers who might have already seen the > entry, but still important > enough to fix the public record, then what ... ? It sounds like you are contradicting yourself. It isn't important enough to fix yet it is. I've said all I have to say about this issue. -1 on this Pace. So far there haven't been any convincing arguments outside of highly contrived, hypothetical scenarios where it could be useful. On the other hand, it is highly likely that the existence of this atom:updated and atom:modified will confuse consumers and producers of Atom feeds. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Oct 29 09:32:56 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 JAA28357 for ; Fri, 29 Oct 2004 09:32:54 -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 i9TDRlsI047392; Fri, 29 Oct 2004 06:27:47 -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 i9TDRlpQ047391; Fri, 29 Oct 2004 06:27:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TDRktX047307 for ; Fri, 29 Oct 2004 06:27:46 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TCkbQd021998; Fri, 29 Oct 2004 13:46:37 +0100 (BST) Message-ID: <41823BAD.70409@mac.com> Date: Fri, 29 Oct 2004 13:46:37 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray , atom Syntax Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > I just created PaceFieldingLinks to capture Roy's proposal: > http://www.intertwingly.net/wiki/pie/PaceFieldingLinks > > I also noted that existing link-related Paces are not up-to-date with > the format-03 draft. I think I'll ask Sam to consider closing any > link-related Paces that haven't been updated relative to the current > format draft when the time comes to discuss them again. I've updated PaceLinkByLocation. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 09:32:58 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 JAA28375 for ; Fri, 29 Oct 2004 09:32:57 -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 i9TDRmsY047414; Fri, 29 Oct 2004 06:27: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 i9TDRmfR047413; Fri, 29 Oct 2004 06:27:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TDRktZ047307 for ; Fri, 29 Oct 2004 06:27:48 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TCrnFu025137; Fri, 29 Oct 2004 13:53:49 +0100 (BST) Message-ID: <41823D5D.2050400@mac.com> Date: Fri, 29 Oct 2004 13:53:49 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > I just created PaceFieldingLinks to capture Roy's proposal: > http://www.intertwingly.net/wiki/pie/PaceFieldingLinks > > I also noted that existing link-related Paces are not up-to-date with > the format-03 draft. I think I'll ask Sam to consider closing any > link-related Paces that haven't been updated relative to the current > format draft when the time comes to discuss them again. -Tim Can I ask Tim, why do you hate XML namespaces? Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 09:34:36 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 JAA28428 for ; Fri, 29 Oct 2004 09:34:34 -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 i9TDRn2r047428; Fri, 29 Oct 2004 06:27:49 -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 i9TDRn9h047427; Fri, 29 Oct 2004 06:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TDRmTu047345 for ; Fri, 29 Oct 2004 06:27:48 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TD8g8o002633; Fri, 29 Oct 2004 14:08:44 +0100 (BST) Message-ID: <418240DB.6080800@mac.com> Date: Fri, 29 Oct 2004 14:08:43 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > Without atom:modified, such changes might well never propagate through > systems, even if more recently retrieved. I've got at least one system > elsewhere where propagation is optimised to ignore those things which have > apparently not been modified. Saves bandwidth, saves CPU, saves time, saves > resources. I won't be able to do the same optimisations with Atom if I don't > have atom:modified. Why do you keep pretending that hash functions do not exist? Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 09:47: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 JAA29798 for ; Fri, 29 Oct 2004 09:47: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 i9TDestn056538; Fri, 29 Oct 2004 06:40:54 -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 i9TDesVb056537; Fri, 29 Oct 2004 06:40:54 -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 i9TDesU0056428 for ; Fri, 29 Oct 2004 06:40:54 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 29395 messnum 379509 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 29 Oct 2004 13:40:48 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail05.svc.cra.dublin.eircom.net (qp 29395) with SMTP; 29 Oct 2004 13:40:48 -0000 Message-ID: <4182485C.5070800@dehora.net> Date: Fri, 29 Oct 2004 14:40:44 +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: PaceDateModified References: <418240DB.6080800@mac.com> In-Reply-To: <418240DB.6080800@mac.com> 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 Graham Parks wrote: > > Eric Scheid wrote: > >> Without atom:modified, such changes might well never propagate through >> systems, even if more recently retrieved. I've got at least one system >> elsewhere where propagation is optimised to ignore those things which >> have >> apparently not been modified. Saves bandwidth, saves CPU, saves time, >> saves >> resources. I won't be able to do the same optimisations with Atom if I >> don't >> have atom:modified. > > > Why do you keep pretending that hash functions do not exist? They don't exist. Not in this spec. After countless posts on dates, I still don't understand the expected behavioural difference between modified and updated. What is it you all arguing about? cheers Bill From owner-atom-syntax@mail.imc.org Fri Oct 29 09:50: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 JAA29880 for ; Fri, 29 Oct 2004 09:50: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 i9TDj6qG059393; Fri, 29 Oct 2004 06:45: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 i9TDj6wo059391; Fri, 29 Oct 2004 06:45:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TDj65Z059378 for ; Fri, 29 Oct 2004 06:45:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so59969rnk for ; Fri, 29 Oct 2004 06:45:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=de0PG1Tp3QM/kqOgn4boFb7ZSq9Ku8CLrHU5/Q8D9Wmkv8YZVrdFrYH3V8SNi/xXHw4GS5WYvmtfhJIDljqcHtxrA/KwdzYZuTgbPbNvwlxl9CpdFPnQvAeQfrgCRJ7zzYC2lMqcGahCH3y4QbW1ncwVCmecf695DTWS5xojJC8= Received: by 10.38.8.65 with SMTP id 65mr227185rnh; Fri, 29 Oct 2004 06:45:07 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 06:45:07 -0700 (PDT) Message-ID: <1f2ed5cd0410290645689fdc77@mail.gmail.com> Date: Fri, 29 Oct 2004 15:45:07 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceDateModified Cc: atom-syntax@imc.org, norman.walsh@Sun.COM In-Reply-To: <20041029124447.14794.qmail@web40802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd041029030079781412@mail.gmail.com> <20041029124447.14794.qmail@web40802.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 05:44:47 -0700 (PDT), Dare Obasanjo wrote: > --- Danny Ayers wrote: > > I am subscribed to the folllowing feeds: > > > > http://planetrdf.com/index.rdf > > http://planet.xmlhack.com/index.rdf > > > http://rss.pubsub.com/37/b5/3778cec38f25c9f8282681622a.xml > > > > The first is Planet XMLhack, the second Planet RDF. > > The third is a > > PubSub subscription. > > > > Whenever Norm Walsh posts to his blog, the items are > > picked up on the > > first two feeds. If he happens to mention > > "environment-friendly lawn > > mowers" it will be picked up on the third as well. > > So my aggregator > > will receive three copies of the same item. > > > > Now assume all these systems are using Atom. Norm > > corrects a spelling > > mistake. My aggregator receives two copies of the > > entry prior to the > > correction, one after. They all have the same > > atom:updated value, as > > it was only a minor change. > > > > How does my aggregator know which version of the > > entry to display? > > First of all this assumes the aggregator tracks items > across different feeds with the same ID. So far I > haven't seen an aggregator that does this, I could do > this in RSS Bandit but don't due to the high cost of > tracking this memory/perf wise. That's down to the implementation of RSS Bandit. Tracking duplicates is cheap and trivial if you're using a SQL database, you can even use the as a key. Same applies with RDF-based aggregators, where the item URI is the key. > More importantly, your scenario assumes that all 3 > feeds are republishing the atom:modified date from > Norm's feed which in many cases may not be true. What > if PlanetXMLHack upgrades their server software which > fixes some transcription errors that have occured in > how they emit feeds (I believe Sam pointed some issues > out in his blog) won't they change atom:modified? What > if this atom:modified date for the now correctly > transcribed entry is later than the typo fixed entry > in Norm's feed? No. The atom:modified value would be set at source (in Norm's feed). No intermediary should interfere with this. If the aggregator blindly accepted > atom:modified across feeds then it would replace the > typo fixed entry with the entry still containing the > typo because one of the Planet* feeds changed some of > their feed generating code. Incorrect assumption. > Using atom:modified in this scenario is a hack that > will most likely break down more often than it would > work. With atom:updated alone, detecting the most recent version of an entry is impossible. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 09:57:40 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 JAA00685 for ; Fri, 29 Oct 2004 09:57:39 -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 i9TDoiAb063384; Fri, 29 Oct 2004 06:50: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 i9TDoirh063378; Fri, 29 Oct 2004 06:50:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TDohVC063342 for ; Fri, 29 Oct 2004 06:50:44 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so69739rnb for ; Fri, 29 Oct 2004 06:50:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=h/Z0AfqoNAQzVdYJf+Grk+O3rl6hN8GsIpHiCfKPJZ1lnvl8mykKz2L4ymj+qD8HnKkxmr0dWkk2EWnWUcmrYWZjrjh8Pgrr30dNGP245EVmIVCw4fFl5UL7tWqJNPNoxUwtz+s35isQyHGcmP56soY0UuRQyKGaymaZdF0WgaU= Received: by 10.38.98.30 with SMTP id v30mr262440rnb; Fri, 29 Oct 2004 06:50:35 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 06:50:35 -0700 (PDT) Message-ID: <1f2ed5cd041029065068f70b54@mail.gmail.com> Date: Fri, 29 Oct 2004 15:50:35 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceDateModified Cc: Eric Scheid , Atom Syntax In-Reply-To: <20041029131026.72619.qmail@web40803.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041029131026.72619.qmail@web40803.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 06:10:26 -0700 (PDT), Dare Obasanjo wrote: So far there haven't been any convincing > arguments outside of highly contrived, hypothetical > scenarios where it could be useful. I gave a practical, real, current scenario with the feeds containing Norm's posts. It would be useful in the sense that: 1. I don't want 3 copies of the same entry (with or without minor changes) 2. I would prefer to see the most recent version of a post (after any minor changes) Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 10:03: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 KAA01185 for ; Fri, 29 Oct 2004 10:03: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 i9TDvbMA068297; Fri, 29 Oct 2004 06:57:37 -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 i9TDvbTG068294; Fri, 29 Oct 2004 06:57:37 -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 i9TDvagu068246 for ; Fri, 29 Oct 2004 06:57:36 -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 1CNXG1-0004xE-Gt; Fri, 29 Oct 2004 13:57:33 +0000 Message-ID: <41824C4C.7040900@franklinmint.fm> Date: Fri, 29 Oct 2004 09:57:32 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceDateModified References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> In-Reply-To: <4182485C.5070800@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > After countless posts on dates, I still don't understand the expected > behavioural difference between modified and updated. What is it you all > arguing about? > This is what the modified people want: Title: "I love HTLM!" oops, typo Title: "I love HTML!" [atom:modifed changed] Title: "I love Atom!" [atom:updated changed, loud sirens go off in the aggregator, etc] Why they think this is a useful distinction and/or something that will work is beyond me. It's just a timestamp version of the X-Priority email header. They don't want to use atom:updated for typos and such because that's been reserved for "radical changes in content" in their minds. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 10:17:44 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 KAA03330 for ; Fri, 29 Oct 2004 10:17: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 i9TE8W11074439; Fri, 29 Oct 2004 07:08: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 i9TE8WLf074438; Fri, 29 Oct 2004 07:08:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TE8WYu074420 for ; Fri, 29 Oct 2004 07:08:32 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so70731rnb for ; Fri, 29 Oct 2004 07:08:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eEmxIZE+YbAO7hsZ8w6rx+XzQOwRc4gnMkxB5bvDuHU0C1YMoJtmgz8TBxO0ieLFjYlMhcX2nYLxlOZ4ZA8t6U6l9rNbqABhBDNmwKDH5Q4H8kmV03s4JOWXvZy00GdvM6BeD9cKW+DZo758qywmJ0RmU2fv6+JB0EfbzG6vZbk= Received: by 10.38.98.30 with SMTP id v30mr271265rnb; Fri, 29 Oct 2004 07:08:30 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 07:08:30 -0700 (PDT) Message-ID: <1f2ed5cd04102907085d5a4dfc@mail.gmail.com> Date: Fri, 29 Oct 2004 16:08:30 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <41824C4C.7040900@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824C4C.7040900@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 09:57:32 -0400, Robert Sayre wrote: > They don't want to use atom:updated for typos and such because that's > been reserved for "radical changes in content" in their minds. Yep, as a direct result of what it says in the spec: [[ The "atom:updated" element is a Date Construct indicating the most recent date and time when a change was made to the entry which the publisher wishes to bring to the attention of subscribers. Such changes will typically not include minor adjustments like spelling and grammatical corrections. ]] -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 10:21:40 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 KAA03850 for ; Fri, 29 Oct 2004 10:21:39 -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 i9TEDkNj077477; Fri, 29 Oct 2004 07:13: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 i9TEDkae077475; Fri, 29 Oct 2004 07:13:46 -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 i9TEDjTx077461 for ; Fri, 29 Oct 2004 07:13:45 -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 1CNXVZ-0007EB-I3; Fri, 29 Oct 2004 14:13:37 +0000 Message-ID: <41825012.4070507@franklinmint.fm> Date: Fri, 29 Oct 2004 10:13:38 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax Subject: Re: PaceDateModified References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824C4C.7040900@franklinmint.fm> <1f2ed5cd04102907085d5a4dfc@mail.gmail.com> In-Reply-To: <1f2ed5cd04102907085d5a4dfc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > On Fri, 29 Oct 2004 09:57:32 -0400, Robert Sayre wrote: > > >>They don't want to use atom:updated for typos and such because that's >>been reserved for "radical changes in content" in their minds. > > > Yep, as a direct result of what it says in the spec: > > [[ > The "atom:updated" element is a Date Construct indicating the most > recent date and time when a change was made to the entry which the > publisher wishes to bring to the attention of subscribers. Such > changes will typically not include minor adjustments like spelling and > grammatical corrections. > ]] You might want to read the spec, since that's not quite what it says [[ The "atom:updated" element is a Date construct indicating the most recent instant in time when a change to the entry was made that the publisher wishes to bring to the attention of subscribers. For example, such changes might not include minor adjustments like spelling and grammatical corrections. ]] Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 10:30:29 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 KAA04604 for ; Fri, 29 Oct 2004 10:30:28 -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 i9TEL4HH080995; Fri, 29 Oct 2004 07:21:04 -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 i9TEL4PR080994; Fri, 29 Oct 2004 07:21:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEL34o080890 for ; Fri, 29 Oct 2004 07:21:03 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 583F2CD for ; Fri, 29 Oct 2004 07:20:59 -0700 (PDT) Received: from [127.0.0.1] (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9TEKvhc020720 for ; Fri, 29 Oct 2004 07:20:58 -0700 (PDT) Date: Fri, 29 Oct 2004 07:16:32 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: PaceDateModified Message-ID: <76ACFBED7878B8FCC4E2E054@[10.238.0.81]> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think there are a couple of modes for Atom feeds. One is the cached, loose-consistency, bandwidth-efficient distribution mode. DateUpdated is exactly what is needed for this. This mode is a REST architecture approach. Also, most consumers in this mode only need the most recent content. They do not need an accurate history of all entries and changes to entries. The other is database replication or archiving. For this, we care about a full history, no missed messages, and we need in-entry copies of anything that is necessary for the HTTP protocol. Fo that, DateModified is useful. In particular, we must save DateModified in order to set it in the HTTP header after an archive restore. These two have different requirements, and we need to address them separately. We could also split off archiving from database replication, since archiving is a lot simpler. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Oct 29 10:30: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 KAA04654 for ; Fri, 29 Oct 2004 10:30:46 -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 i9TEP93T083439; Fri, 29 Oct 2004 07:25:09 -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 i9TEP9qN083438; Fri, 29 Oct 2004 07:25:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEP7k4083144 for ; Fri, 29 Oct 2004 07:25:08 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 00:24:44 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 00:24:38 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029131026.72619.qmail@web40803.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 11:10 PM, "Dare Obasanjo" wrote: > It sounds like you are contradicting yourself. It > isn't important enough to fix yet it is. simple concept: there are degrees of importance. > On the other hand, it is highly likely that the > existence of this atom:updated and atom:modified will > confuse consumers and producers of Atom feeds. This is something we can work on, as it mostly involves writing better spec text. Please elaborate. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 10:32: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 KAA04844 for ; Fri, 29 Oct 2004 10:32:46 -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 i9TERlvK085013; Fri, 29 Oct 2004 07:27:47 -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 i9TERlAH085012; Fri, 29 Oct 2004 07:27:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TERj4v084999 for ; Fri, 29 Oct 2004 07:27:46 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 00:27:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 00:27:46 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <418240DB.6080800@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29/10/04 11:08 PM, "Graham Parks" wrote: > Why do you keep pretending that hash functions do not exist? sheesh. grow up. hash functions are very blunt instruments, and would require a lot of complexifying to get them to ignore differences due to XML serialisation, unicode encoding, etc. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 10:50: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 KAA06432 for ; Fri, 29 Oct 2004 10:50:34 -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 i9TEd35q091672; Fri, 29 Oct 2004 07:39:03 -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 i9TEd3XQ091670; Fri, 29 Oct 2004 07:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEd2WG091657 for ; Fri, 29 Oct 2004 07:39:03 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so90431rnl for ; Fri, 29 Oct 2004 07:38:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Dsda/JHEnRSAF7dfuB6lxbj4bH9Gz90L/d8VnEG9bo/2z/yjD9MEnnCXYIYZxb896MpoSjrJCQcV/wvOVg8wtzqdhdI1km6OvDiBxsJXbZINvMTOo93XABceHPGcse2i+wt+MUyqz2O0892JjE5eZWTjA1TPQVLxPKp/8LVbBRg= Received: by 10.38.206.23 with SMTP id d23mr261788rng; Fri, 29 Oct 2004 07:38:55 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 07:38:55 -0700 (PDT) Message-ID: <1f2ed5cd041029073878d3a8a8@mail.gmail.com> Date: Fri, 29 Oct 2004 16:38:55 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <41825012.4070507@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824C4C.7040900@franklinmint.fm> <1f2ed5cd04102907085d5a4dfc@mail.gmail.com> <41825012.4070507@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 10:13:38 -0400, Robert Sayre wrote: > Danny Ayers wrote: > > > > On Fri, 29 Oct 2004 09:57:32 -0400, Robert Sayre wrote: > > > > > >>They don't want to use atom:updated for typos and such because that's > >>been reserved for "radical changes in content" in their minds. > > > > > > Yep, as a direct result of what it says in the spec: > > > > [[ > > The "atom:updated" element is a Date Construct indicating the most > > recent date and time when a change was made to the entry which the > > publisher wishes to bring to the attention of subscribers. Such > > changes will typically not include minor adjustments like spelling and > > grammatical corrections. > > ]] > > You might want to read the spec, since that's not quite what it says > > [[ > The "atom:updated" element is a Date construct indicating the most > recent instant in time when a change to the entry was made that the > publisher wishes to bring to the attention of subscribers. For example, > such changes might not include minor adjustments like spelling and > grammatical corrections. > ]] I apologise, my mental aggregator only had the atom:updated information to work from... -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 10:53: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 KAA06603 for ; Fri, 29 Oct 2004 10:53:45 -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 i9TEhwXt094586; Fri, 29 Oct 2004 07:43:58 -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 i9TEhwme094585; Fri, 29 Oct 2004 07:43:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEhvwh094528 for ; Fri, 29 Oct 2004 07:43:57 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.97] (tve9bbab.brookes.ac.uk [161.73.18.97]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TE1xqT000491; Fri, 29 Oct 2004 15:02:03 +0100 (BST) Message-ID: <41824D59.9090603@mac.com> Date: Fri, 29 Oct 2004 15:02:01 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceDateModified References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> In-Reply-To: <4182485C.5070800@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > They don't exist. Not in this spec. Why do they need to be in the spec? I don't know what system's Eric was talking about specifically, but I can't imagine a scenario where you need modification dates to detect changes. Calculate a hash of the old and new data, and if the hashes are the same, it hasn't changed. It can't be more expensive than parsing XML to extract the date inside it. > After countless posts on dates, I still don't understand the expected > behavioural difference between modified and updated. What is it you all > arguing about? Updated: Changed only when the publisher wants to flag their data as having changed, which the client can then flag to the suer Modified: Updated whenever any data is changed, for God knows what reason. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 10:56: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 KAA06762 for ; Fri, 29 Oct 2004 10:56:34 -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 i9TEpxbf098921; Fri, 29 Oct 2004 07:51:59 -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 i9TEpxbD098920; Fri, 29 Oct 2004 07:51:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEpwjE098851 for ; Fri, 29 Oct 2004 07:51:58 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 67330 invoked from network); 29 Oct 2004 14:51:53 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 29 Oct 2004 14:51:53 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Fri, 29 Oct 2004 15:51:53 +0100 Message-ID: <1099061513.41825909d73c0@webmail.djpowell.net> Date: Fri, 29 Oct 2004 15:51:53 +0100 From: David Powell To: Bill de =?iso-8859-1?b?aNNyYQ==?= Cc: Atom Syntax Subject: Re: PaceDateModified References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> In-Reply-To: <4182485C.5070800@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Bill de hÓra : > After countless posts on dates, I still don't understand the > expected behavioural difference between modified and updated. What > is it you all arguing about? This is how I believe it works, but the anti-atom:modifed people out there presumably have a different model (using hashes I guess?): Assuming you have a copy of an entry in your aggregator, and you then refetch the feed: If the atom:updated for the original entry is newer than atom:updated in the recently fetched entry, then the aggregator should mark the entry as unread - or something similar that is appopriate for the user-agent. atom:modified on the other hand, is the equivalent of HTTP's Last-Modified header. It acts as a cache validator. If atom:modified is updated, then the entry should still be fully processed by clients, but it shouldn't be marked as unread. If you modify an entry without updating atom:modifed, then you can expect that some readers may miss the change, because of intermediaries, or aggregators which only reprocess entries that have changed. -- Dave From owner-atom-syntax@mail.imc.org Fri Oct 29 10:57:26 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 KAA06898 for ; Fri, 29 Oct 2004 10:57:26 -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 i9TEosJV098410; Fri, 29 Oct 2004 07:50:54 -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 i9TEos7A098409; Fri, 29 Oct 2004 07:50:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TEornx098359 for ; Fri, 29 Oct 2004 07:50:54 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 34630 messnum 5041519 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 29 Oct 2004 14:50:50 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail04.svc.cra.dublin.eircom.net (qp 34630) with SMTP; 29 Oct 2004 14:50:50 -0000 Message-ID: <418258C5.5020309@dehora.net> Date: Fri, 29 Oct 2004 15:50:45 +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: I'm changed?... Changed how? [was PaceDateModified] References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824C4C.7040900@franklinmint.fm> In-Reply-To: <41824C4C.7040900@franklinmint.fm> 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 Robert Sayre wrote: > Why they think this is a useful distinction and/or something that will > work is beyond me. It's just a timestamp version of the X-Priority email > header. > > They don't want to use atom:updated for typos and such because that's > been reserved for "radical changes in content" in their minds. Thanks Robert. I don't see how having modified+updated can be easily specified for a syndication format. Making "changed" a grayscale of states rather than a bitflip* seems rather complicated (even if it's only two or three states). On the offchance that this is a terminology spat, how about dropping both and using atom:changed? We can leave the inevitable "I'm changed? Changed how? Changed like a clown?" for non-core extensions. cheers Bill * which reminds me a bit of those issue trackers or log tools that have plenty of fine-grained states but which no-one uses in practice. From owner-atom-syntax@mail.imc.org Fri Oct 29 10:58: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 KAA06963 for ; Fri, 29 Oct 2004 10:58: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 i9TEs72v000349; Fri, 29 Oct 2004 07:54:07 -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 i9TEs7WJ000348; Fri, 29 Oct 2004 07:54:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEs6wH000333 for ; Fri, 29 Oct 2004 07:54:07 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 00:54:13 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 00:54:07 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41825012.4070507@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 12:13 AM, "Robert Sayre" wrote: >> Yep, as a direct result of what it says in the spec: >> >> [[ >> The "atom:updated" element is a Date Construct indicating the most >> recent date and time when a change was made to the entry which the >> publisher wishes to bring to the attention of subscribers. Such >> changes will typically not include minor adjustments like spelling and >> grammatical corrections. >> ]] > > You might want to read the spec, since that's not quite what it says > > [[ > The "atom:updated" element is a Date construct indicating the most > recent instant in time when a change to the entry was made that the > publisher wishes to bring to the attention of subscribers. For example, > such changes might not include minor adjustments like spelling and > grammatical corrections. > ]] Danny quoted the Pace, rather than the most recent iteration of the spec. No harm, no foul. Can you explain what the *real* difference is between the two wordings, because I can't see any difference. e. ps: and there shouldn't be any real difference in meanings, right? otherwise the spec editors have overstepped their mark, right? From owner-atom-syntax@mail.imc.org Fri Oct 29 11:01: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 LAA07142 for ; Fri, 29 Oct 2004 11:01: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 i9TEuYEo001514; Fri, 29 Oct 2004 07:56: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 i9TEuYd2001513; Fri, 29 Oct 2004 07:56:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TEuX0h001477 for ; Fri, 29 Oct 2004 07:56:34 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so63221rnk for ; Fri, 29 Oct 2004 07:56:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EtiVAenZlPIEsKd6LmEzWqcz3tHZsiPmB0NV/jbBLAQR3oSbzRG/tJCzT9UU2ut0wLQE70doExVxqlf55AoAkK3M2bLdeN1VNVL6MWPS43of44Uqx9vboeasAXKigNBq6RqF7dLt4eRNABk4Qk8Z8rzCyeC8oGpkm+HPko0MeM8= Received: by 10.38.8.65 with SMTP id 65mr265194rnh; Fri, 29 Oct 2004 07:56:33 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 07:56:32 -0700 (PDT) Message-ID: <1f2ed5cd041029075694ee80d@mail.gmail.com> Date: Fri, 29 Oct 2004 16:56:32 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Walter Underwood Subject: Re: PaceDateModified Cc: Atom Syntax In-Reply-To: <76ACFBED7878B8FCC4E2E054@10.238.0.81> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 07:16:32 -0700, Walter Underwood wrote: > > I think there are a couple of modes for Atom feeds. > > One is the cached, loose-consistency, bandwidth-efficient distribution > mode. DateUpdated is exactly what is needed for this. This mode is a > REST architecture approach. Also, most consumers in this mode only > need the most recent content. But that's just it - you can't tell the most recent content from atom:updated, only the version the publisher last considered to be a significant revision. Accurate archiving in these circumstances is a non-starter. The only changes that can be detected are those declared by the publisher, or which by luck happen to have been intercepted in real time in live feeds. I can accept that archiving may be considered an edge case. But not being able to tell which of several entries is the most recent is close to the core of syndication, whether or not certain individual aggregators have the capability to use the information. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 11:04: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 LAA07400 for ; Fri, 29 Oct 2004 11:04:34 -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 i9TExphH003155; Fri, 29 Oct 2004 07:59:51 -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 i9TExpxW003154; Fri, 29 Oct 2004 07:59:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TExnCU003100 for ; Fri, 29 Oct 2004 07:59:50 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 1761 messnum 5114832 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 29 Oct 2004 14:59:46 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail13.svc.cra.dublin.eircom.net (qp 1761) with SMTP; 29 Oct 2004 14:59:46 -0000 Message-ID: <41825ADE.1070006@dehora.net> Date: Fri, 29 Oct 2004 15:59: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 To: Atom Syntax Subject: Re: PaceDateModified References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824D59.9090603@mac.com> In-Reply-To: <41824D59.9090603@mac.com> 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 Graham Parks wrote: > Bill de hÓra wrote: > >> They don't exist. Not in this spec. > > > Why do they need to be in the spec? All I'm saying is that we can't make assumptions about the presence of a hash function unless we spec a hash function. I don't know what system's Eric was > talking about specifically, but I can't imagine a scenario where you > need modification dates to detect changes. Calculate a hash of the old > and new data, and if the hashes are the same, it hasn't changed. It > can't be more expensive than parsing XML to extract the date inside it. I use something very this to manage RDF literals. But it's a private detail of a system, not a public detail of a spec. > Updated: Changed only when the publisher wants to flag their data as > having changed, which the client can then flag to the suer > Modified: Updated whenever any data is changed, for God knows what reason. Thanks. cheers Bill From owner-atom-syntax@mail.imc.org Fri Oct 29 11:06:07 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 LAA07650 for ; Fri, 29 Oct 2004 11:06: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 i9TF11RA003866; Fri, 29 Oct 2004 08:01:01 -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 i9TF11h8003865; Fri, 29 Oct 2004 08:01:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF0xfX003823 for ; Fri, 29 Oct 2004 08:01:00 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so73704rnb for ; Fri, 29 Oct 2004 08:01:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CAzsEby2noAD07gPE20Be/qvF8G3BywGzKmdGOq/w/bbjjAKqn+x8+r/YfO2uCkkDtjgAMB30vct5uaqgZCnCptpMwWszdkHIhJZSYVt28YZfuLzZX5AQpHC9pRPEUNcbPBYvvUGA4F1jUosTxSgwY47EDKzjtn3CUNhnrOJig0= Received: by 10.38.98.30 with SMTP id v30mr300194rnb; Fri, 29 Oct 2004 08:01:01 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 08:01:01 -0700 (PDT) Message-ID: <1f2ed5cd04102908013bd4ac4a@mail.gmail.com> Date: Fri, 29 Oct 2004 17:01:01 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Parks Subject: Re: PaceDateModified Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <41824D59.9090603@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824D59.9090603@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9TF11fX003859 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 29 Oct 2004 15:02:01 +0100, Graham Parks wrote: > > Bill de hÓra wrote: > > > They don't exist. Not in this spec. > > Why do they need to be in the spec? I don't know what system's Eric was > talking about specifically, but I can't imagine a scenario where you > need modification dates to detect changes. Calculate a hash of the old > and new data, and if the hashes are the same, it hasn't changed. It > can't be more expensive than parsing XML to extract the date inside it. It's not the changing that's a problem, it's the chronological order. You are assuming you know which is the new and which is the old data. If the entries have come down different routes, as in the scenario I described, you can tell they're different, but not which is newer. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 11:10: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 LAA08027 for ; Fri, 29 Oct 2004 11:10: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 i9TF4naP006572; Fri, 29 Oct 2004 08:04:49 -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 i9TF4nU7006567; Fri, 29 Oct 2004 08:04:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TF4mIu006541 for ; Fri, 29 Oct 2004 08:04:48 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 01:04:55 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 01:04:49 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41824D59.9090603@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 12:02 AM, "Graham Parks" wrote: > I don't know what system's Eric was talking about specifically, but I can't > imagine a scenario where you need modification dates to detect changes. > Here's something I did just tonite: I accessed a large online data store, used FTP to get directory listings, and then downloaded just the files which have a different date from what I have locally. (this is not a perfect analog for atom entries being passed around, but bear with me) The alternative is to download all the files just so a hash could be calculated, and then ignore those whose hash was no different. But lets say we avoid that by having the remote system calculate the hashes ... this would result in another, different problem: the remote file has hash ABC, while the local file has hash XYZ. They are thus "different", but which is the more recent file? Should the remote file be downloaded to replace the local, or should the local be uploaded to replace the remote. Hashes won't tell you that. Changes in atom:modified tell us (1) something has changed, without having to try to spot the change amongst the XML serialisation, and (2) which of the two versions is the more recent. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 11:14:23 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 LAA08260 for ; Fri, 29 Oct 2004 11:14:22 -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 i9TF84w9009140; Fri, 29 Oct 2004 08:08:04 -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 i9TF84RF009139; Fri, 29 Oct 2004 08:08:04 -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 i9TF83pl009127 for ; Fri, 29 Oct 2004 08:08:04 -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 1CNYME-00066c-VO; Fri, 29 Oct 2004 15:08:03 +0000 Message-ID: <41825CD3.9050006@franklinmint.fm> Date: Fri, 29 Oct 2004 11:08:03 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > > ps: and there shouldn't be any real difference in meanings, right? otherwise > the spec editors have overstepped their mark, right? > You are free to squawk if you feel the spec editors have written down their own opinion instead of WG consensus. If the co-chairs agree, the editors will cheerfully revise the specification as instructed. In this case, I'd say 3 or 4 people have bigger plans for atom:updated than other supporters do. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 11:28: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 LAA09137 for ; Fri, 29 Oct 2004 11:28: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 i9TFKGhn016716; Fri, 29 Oct 2004 08:20: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 i9TFKGp2016715; Fri, 29 Oct 2004 08:20:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TFKGVf016702 for ; Fri, 29 Oct 2004 08:20:16 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so64362rnk for ; Fri, 29 Oct 2004 08:20:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=j9xQ4Ry3pcHo/OKbdszCGiEMW8SabqkfWabNQUIyrpSBXLq31w0IeqJLltkehj/ZfxLY/TnafigTlG94mLTYpoXSZ+aX28n9aKuU7MM4LwKhashLKNx3SMCs7DHN+JEo64WxXxcQrDJdLtKDTNcZAl64J4tMOFf0z5A/Cs6dSb0= Received: by 10.38.8.65 with SMTP id 65mr280256rnh; Fri, 29 Oct 2004 08:20:16 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 08:20:16 -0700 (PDT) Message-ID: <1f2ed5cd0410290820391c7097@mail.gmail.com> Date: Fri, 29 Oct 2004 17:20:16 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: Eric Scheid , Atom Syntax In-Reply-To: <41825CD3.9050006@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41825CD3.9050006@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 11:08:03 -0400, Robert Sayre wrote: > In this case, I'd say 3 or 4 people have bigger plans for atom:updated > than other supporters do. Care to elaborate? I'd like to find out why there's such resistance to something that fixes something that seems, as it stands, a pretty obvious shortcoming. Are they planning on using atom:updated to signal typo changes? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 11:49: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 LAA10470 for ; Fri, 29 Oct 2004 11:49:45 -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 i9TFi9vJ032359; Fri, 29 Oct 2004 08:44:09 -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 i9TFi9kK032358; Fri, 29 Oct 2004 08:44:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TFi7Eo032296 for ; Fri, 29 Oct 2004 08:44:08 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 44so448037wri for ; Fri, 29 Oct 2004 08:43:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=d+bjg5mXmDD4p16098Oc+Wl8m3AfXvhjViECotGE+flrZCbla6Y8dgjCp3tYUKbw2T8WlrI/FOk0bOi5LIEbXWIQXaHBN1WhxkrB2d62qnMDiUMsMUkAAZ7GSiZOzHoiNgFPf0G4DF0VrdsF7GrH2aRlK85jO4WG7mw0ZmEuFqA= Received: by 10.38.73.43 with SMTP id v43mr924436rna; Fri, 29 Oct 2004 08:43:59 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Fri, 29 Oct 2004 08:43:59 -0700 (PDT) Message-ID: <540e373204102908437072d80@mail.gmail.com> Date: Fri, 29 Oct 2004 10:43:59 -0500 From: "Roger B." Reply-To: "Roger B." To: Danny Ayers Subject: Re: PaceDateModified Cc: Atom Syntax In-Reply-To: <1f2ed5cd041029075694ee80d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > But that's just it - you can't tell the most recent content from > atom:updated, only the version the publisher last considered to be a > significant revision. Danny: You're over-thinking it. (a) The definition of "significant" is left to the publisher. (b) Last I looked at the list of vendor-specific dates on the wiki, not much of anyone had anything more subtle than a plain ol' "last modified" date for tracking changes. Put them both together and it suggests that the data you're looking for will probably end up in atom:updated. In practical terms, atom:updated is simply a version of atom:modified that gives the publisher the option *not* to indicate a change. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Oct 29 11:49:57 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 LAA10498 for ; Fri, 29 Oct 2004 11:49:57 -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 i9TFhdFg032055; Fri, 29 Oct 2004 08:43:39 -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 i9TFhdrP032054; Fri, 29 Oct 2004 08:43:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TFhdY1032007 for ; Fri, 29 Oct 2004 08:43:39 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@ms8.netsolmail.com [216.168.230.180] (may be forged)) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9TFhFq5028481; Fri, 29 Oct 2004 11:43:27 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWQ46569 (AUTH bob@wyman.us); Fri, 29 Oct 2004 11:43:14 -0400 (EDT) Message-Id: <200410291543.BWQ46569@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham Parks'" , "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" Cc: "'Atom Syntax'" Subject: RE: PaceDateModified Date: Fri, 29 Oct 2004 11:42:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS9x5k4F4MUmnalSiuSF/C6PzuGmAAAu2oA In-Reply-To: <41824D59.9090603@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm concerned that the current discussion seems to indicate that change detection may be irrelevant and inappropriate for both desktop aggregators and in-channel intermediaries. If this is correct, then any discussion of hashing is irrelevant to the discussion. I believe what is being suggested is something like the following: If atom:updated is used to flag only those changes that the author of an entry wishes to bring to the attention of readers, then it seems to me that intermediaries should respect the publisher's statements and ignore any updates that are not so flagged. If this is correct, then any change detection on the part of intermediaries should be considered a bad thing. Intermediaries should not be generating entry hashes or otherwise trying to detect changes. The model seems to be that an aggregator needs to build a database of entries that has columns for atom:id and atom:updated. I should then only process those entries that have atom:updated values that are greater then what was previously stored for any given atom:id. No matter how great the difference may be between two versions of an entry, I should not pay any attention to the difference unless explicitly "told to" by a new atom:updated value. This implies that if I find multiple versions of an entry, I should ignore all but the *first* instance of an entry found with any particular atom:updated value. I should not be concerned with identifying the "latest" version since any version that shares the same atom:updated value is equivalent in the opinion of the publisher. The opinion of the publisher is paramount in these issues. Does what I've said above match what is believed by those who support atom:updated to the exclusion of atom:modified? bob wyman From owner-atom-syntax@mail.imc.org Fri Oct 29 11:57:13 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 LAA10827 for ; Fri, 29 Oct 2004 11:57:13 -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 i9TFnalY035604; Fri, 29 Oct 2004 08:49:36 -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 i9TFna1x035603; Fri, 29 Oct 2004 08:49:36 -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 i9TFnZgw035592 for ; Fri, 29 Oct 2004 08:49:36 -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 1CNZ0P-000479-Lc; Fri, 29 Oct 2004 15:49:33 +0000 Message-ID: <4182668D.6030505@franklinmint.fm> Date: Fri, 29 Oct 2004 11:49:33 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Eric Scheid , Atom Syntax Subject: Re: PaceDateModified References: <41825CD3.9050006@franklinmint.fm> <1f2ed5cd0410290820391c7097@mail.gmail.com> In-Reply-To: <1f2ed5cd0410290820391c7097@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > Are they planning on using atom:updated to signal typo changes? > That's what I'll be doing. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 11:57:28 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 LAA10852 for ; Fri, 29 Oct 2004 11:57:27 -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 i9TFnn6x035730; Fri, 29 Oct 2004 08:49:49 -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 i9TFnnE1035729; Fri, 29 Oct 2004 08:49:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TFnniI035720 for ; Fri, 29 Oct 2004 08:49:49 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so65788rnk for ; Fri, 29 Oct 2004 08:49:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=F2XGV6azlrDP4SJ94meubKm6KvtGIHfKwD5RTcCvOpTaQ4cLHadykOsq6AR4YzYnpjPbSDKv3ghVyS+m5c06CObXSFlfoJWKwvWWYfK96OiWtbbINAle2jywnPiFeWKohipMvAN2ExdSJm95UR1/FFsHCXxP+v3S5Msz/2/T1Nk= Received: by 10.38.8.65 with SMTP id 65mr298400rnh; Fri, 29 Oct 2004 08:49:42 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 08:49:42 -0700 (PDT) Message-ID: <1f2ed5cd041029084976645ddf@mail.gmail.com> Date: Fri, 29 Oct 2004 17:49:42 +0200 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: I'm changed?... Changed how? [was PaceDateModified] Cc: Atom Syntax In-Reply-To: <418258C5.5020309@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <418240DB.6080800@mac.com> <4182485C.5070800@dehora.net> <41824C4C.7040900@franklinmint.fm> <418258C5.5020309@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9TFnniI035723 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 29 Oct 2004 15:50:45 +0100, Bill de hÓra wrote: > I don't see how having modified+updated can be easily specified for > a syndication format. Making "changed" a grayscale of states rather > than a bitflip* seems rather complicated (even if it's only two or > three states). It isn't really grayscale, the values are qualitatively different, maybe: subjective change : atom:updated objective change : atom:modified (subjective from the publisher's point of view, objective from a diff point of view) Here's a use case: Publisher: A CMS is used for software project documentation. The documentation is under continuous review, minor changes being made to the wording, typos etc. With every change, the entry is republished with a corresponding change in the atom:modified date. Periodically there is a significant update - a new version release. The entry is republished with a new value in the atom:updated element. Consumer: Receives all entries, changing content in the local store whenever the atom:modified value has changed. Whenever the user looks in their archives, they see the latest content. *But* the UI only re-displays the entry when there has been a significant change. This isn't contrived, here are two examples that might benefit from this approach, both of which have been pushed into a feed: http://norman.walsh.name/2004/projects/rdftwig http://www.wasab.dk/morten/blog/archives/2004/07/05/wordpress-plugin-foaf-output Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 12:08: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 MAA11792 for ; Fri, 29 Oct 2004 12:08: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 i9TG2RmK043205; Fri, 29 Oct 2004 09:02:27 -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 i9TG2RLM043204; Fri, 29 Oct 2004 09:02:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40826.mail.yahoo.com (web40826.mail.yahoo.com [66.218.92.73]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TG2Qlb043133 for ; Fri, 29 Oct 2004 09:02:26 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029160224.46570.qmail@web40826.mail.yahoo.com> Received: from [24.18.132.123] by web40826.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 09:02:24 PDT Date: Fri, 29 Oct 2004 09:02:24 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: "Roger B." , Danny Ayers Cc: Atom Syntax In-Reply-To: <540e373204102908437072d80@mail.gmail.com> 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: --- "Roger B." wrote: > > Danny: You're over-thinking it. > > (a) The definition of "significant" is left to the > publisher. > > (b) Last I looked at the list of vendor-specific > dates on the wiki, > not much of anyone had anything more subtle than a > plain ol' "last > modified" date for tracking changes. > > Put them both together and it suggests that the data > you're looking > for will probably end up in atom:updated. In > practical terms, > atom:updated is simply a version of atom:modified > that gives the > publisher the option *not* to indicate a change. Exactly. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 29 12:13: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 MAA12035 for ; Fri, 29 Oct 2004 12:13: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 i9TG8IIe047126; Fri, 29 Oct 2004 09:08: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 i9TG8IZb047125; Fri, 29 Oct 2004 09:08:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TG8GXo047102 for ; Fri, 29 Oct 2004 09:08:17 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so78173rnb for ; Fri, 29 Oct 2004 09:08:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nF0/YwWvqpdK1M7jUwru1lp4DJhn130wPIm1qzCK93lCOGU1f9hAX6ZC0208EqiNTJUgOLf7Or1NKW2SwPUhg/IhCiZvhmnMc2JuWiX81V8USLC34MibIos+/PgC2ew4lW2SUFB9//3gkgj1Y4g+WPMopwj9kbphsmVReEcU2To= Received: by 10.38.98.30 with SMTP id v30mr341528rnb; Fri, 29 Oct 2004 09:08:11 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 09:08:11 -0700 (PDT) Message-ID: <1f2ed5cd041029090834fd517d@mail.gmail.com> Date: Fri, 29 Oct 2004 18:08:11 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceDateModified Cc: "Roger B." , Atom Syntax In-Reply-To: <20041029160224.46570.qmail@web40826.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <540e373204102908437072d80@mail.gmail.com> <20041029160224.46570.qmail@web40826.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 09:02:24 -0700 (PDT), Dare Obasanjo wrote: > > > > --- "Roger B." wrote: > > > > Danny: You're over-thinking it. > > > > (a) The definition of "significant" is left to the > > publisher. > > > > (b) Last I looked at the list of vendor-specific > > dates on the wiki, > > not much of anyone had anything more subtle than a > > plain ol' "last > > modified" date for tracking changes. > > > > Put them both together and it suggests that the data > > you're looking > > for will probably end up in atom:updated. In > > practical terms, > > atom:updated is simply a version of atom:modified > > that gives the > > publisher the option *not* to indicate a change. > > Exactly. I look forward to hearing your responses to Bob's last post, about the revisions being considered equivalent. Dare, how do you propose to handle atom:updated in RSS Bandit? Displaying every revision as a new entry, even if (as Robert's proposing) it only contains spelling corrections? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 12:13:20 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 MAA12058 for ; Fri, 29 Oct 2004 12:13:19 -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 i9TG854j046994; Fri, 29 Oct 2004 09:08:05 -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 i9TG85Wj046993; Fri, 29 Oct 2004 09:08:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40812.mail.yahoo.com (web40812.mail.yahoo.com [66.218.78.189]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TG85Hn046924 for ; Fri, 29 Oct 2004 09:08:05 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029160803.32403.qmail@web40812.mail.yahoo.com> Received: from [24.18.132.123] by web40812.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 09:08:03 PDT Date: Fri, 29 Oct 2004 09:08:03 -0700 (PDT) From: Dare Obasanjo Subject: RE: PaceDateModified To: bob@wyman.us, "'Graham Parks'" , "'Bill de \"hÓra'\"" Cc: "'Atom Syntax'" In-Reply-To: <200410291543.BWQ46569@ms8.netsolmail.com> 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: --- Bob Wyman wrote: > > I'm concerned that the current discussion seems to > indicate that > change detection may be irrelevant and inappropriate > for both desktop > aggregators and in-channel intermediaries. If this > is correct, then any > discussion of hashing is irrelevant to the > discussion. I believe what is > being suggested is something like the following: Nope. There are 2 scenarios. (1) Entry is updated in a single feed: Regardless of what dates are attached to the entry, the aggregator can tell if the content differs or not as well as which is newer. (2) Same Entry in Multiple feeds: Most aggregators don't track this today. Even if they did there's still the problem of distinguishing changes to the entry from a republishing feed to changes to the entry in the original feed. Basically atom:modified buys you little if anything. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-atom-syntax@mail.imc.org Fri Oct 29 12:27: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 MAA12864 for ; Fri, 29 Oct 2004 12:27:46 -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 i9TGJGYx054614; Fri, 29 Oct 2004 09:19: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 i9TGJGte054613; Fri, 29 Oct 2004 09:19:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40808.mail.yahoo.com (web40808.mail.yahoo.com [66.218.78.185]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TGJG5j054574 for ; Fri, 29 Oct 2004 09:19:16 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029161914.14866.qmail@web40808.mail.yahoo.com> Received: from [24.18.132.123] by web40808.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 09:19:14 PDT Date: Fri, 29 Oct 2004 09:19:14 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Danny Ayers Cc: "Roger B." , Atom Syntax In-Reply-To: <1f2ed5cd041029090834fd517d@mail.gmail.com> 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: --- Danny Ayers wrote: > > I look forward to hearing your responses to Bob's > last post, about the > revisions being considered equivalent. OK. > Dare, how do you propose to handle atom:updated in > RSS Bandit? > Displaying every revision as a new entry, even if > (as Robert's > proposing) it only contains spelling corrections? Of course not. I'll update the date field of the post. I might also make the post italicized if it has already been read. I'll have to see how often people use atom:updated in feeds to see if it makes the UI more annoying or not to italicize updated posts. Given that RSS Bandit always uses the most recently fetched version of the content for an entry, the only thing atom:updated adds is an explict directive to also update the date field in the UI. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Oct 29 12:28:13 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 MAA12921 for ; Fri, 29 Oct 2004 12:28:12 -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 i9TGLlEV055838; Fri, 29 Oct 2004 09:21:47 -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 i9TGLlmQ055837; Fri, 29 Oct 2004 09:21:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TGLkLx055805 for ; Fri, 29 Oct 2004 09:21:47 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so96396rnl for ; Fri, 29 Oct 2004 09:21:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BfZgBoD6AFoODFi8pgbljGKu36CGY2BMYMfTU9aYF9d/By/k6Ow+Hvpc/Xsd9gJBxW93WKLGUtCYlTi0+L08NK9DWkfGXoS9chELlnpGrKwqFsvHu6bkzdmc6yr4FLISkWXHJpcs5y9Zo69zmQcFtQNYcd8QwXxQQj7tfVc2OYc= Received: by 10.38.206.23 with SMTP id d23mr319745rng; Fri, 29 Oct 2004 09:21:39 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 09:21:39 -0700 (PDT) Message-ID: <1f2ed5cd04102909215ab496c4@mail.gmail.com> Date: Fri, 29 Oct 2004 18:21:39 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceDateModified Cc: bob@wyman.us, Graham Parks , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <20041029160803.32403.qmail@web40812.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410291543.BWQ46569@ms8.netsolmail.com> <20041029160803.32403.qmail@web40812.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 09:08:03 -0700 (PDT), Dare Obasanjo wrote: > > > > > --- Bob Wyman wrote: > > > > > I'm concerned that the current discussion seems to > > indicate that > > change detection may be irrelevant and inappropriate > > for both desktop > > aggregators and in-channel intermediaries. If this > > is correct, then any > > discussion of hashing is irrelevant to the > > discussion. I believe what is > > being suggested is something like the following: > > Nope. > > There are 2 scenarios. > > (1) Entry is updated in a single feed: Regardless of > what dates are attached to the entry, the aggregator > can tell if the content differs or not as well as > which is newer. > > (2) Same Entry in Multiple feeds: Most aggregators > don't track this today. Even if they did there's still > the problem of distinguishing changes to the entry > from a republishing feed to changes to the entry in > the original feed. > > Basically atom:modified buys you little if anything. It buys you 1 and 2. 1. The aggregator being able to tell which items are newer is based on the assumption that the order of items in a feed will be significant. I can't see anything about this in the spec, and if I remember correctly the consensus was around the entry order in the feed not being significant, i.e. "It's the Entries, Stupid!". 2. Can't be done on atom:updated alone (unless you accept that all minor-changed version are equivalent to the first). Can be done with atom:modified. Republishers shouldn't be changing the dates. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 12:28: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 MAA12939 for ; Fri, 29 Oct 2004 12:28: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 i9TGNNl1056935; Fri, 29 Oct 2004 09:23: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 i9TGNNqs056934; Fri, 29 Oct 2004 09:23:23 -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 i9TGNM8r056923 for ; Fri, 29 Oct 2004 09:23:22 -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 1CNZX5-0001IO-Pl; Fri, 29 Oct 2004 16:23:20 +0000 Message-ID: <41826E78.6000207@franklinmint.fm> Date: Fri, 29 Oct 2004 12:23:20 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Dare Obasanjo , "Roger B." , Atom Syntax Subject: Re: PaceDateModified References: <540e373204102908437072d80@mail.gmail.com> <20041029160224.46570.qmail@web40826.mail.yahoo.com> <1f2ed5cd041029090834fd517d@mail.gmail.com> In-Reply-To: <1f2ed5cd041029090834fd517d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > Dare, how do you propose to handle atom:updated in RSS Bandit? > Displaying every revision as a new entry, even if (as Robert's > proposing) it only contains spelling corrections? > I'm not "proposing" anything. As the publisher, I choose what constitutes an important update. I sure hope your aggregator doesn't alert you every time I realize there's a spelling or grammatical error in something I've written. That would be an extremely tedious way to observe well-formed sentences emerge from my mind. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 12:41: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 MAA14047 for ; Fri, 29 Oct 2004 12:41: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 i9TGYlCO064657; Fri, 29 Oct 2004 09:34:47 -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 i9TGYl7q064656; Fri, 29 Oct 2004 09:34:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40802.mail.yahoo.com (web40802.mail.yahoo.com [66.218.78.179]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TGYl8N064582 for ; Fri, 29 Oct 2004 09:34:47 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029163445.38843.qmail@web40802.mail.yahoo.com> Received: from [24.18.132.123] by web40802.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 09:34:45 PDT Date: Fri, 29 Oct 2004 09:34:45 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Danny Ayers Cc: bob@wyman.us, Graham Parks , Bill de "hÓra" , Atom Syntax In-Reply-To: <1f2ed5cd04102909215ab496c4@mail.gmail.com> 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: -- Danny Ayers wrote: > > > Basically atom:modified buys you little if > anything. > > It buys you 1 and 2. > > 1. The aggregator being able to tell which items are > newer is based on > the assumption that the order of items in a feed > will be significant. > I can't see anything about this in the spec, and if > I remember > correctly the consensus was around the entry order > in the feed not > being significant, i.e. "It's the Entries, Stupid!". It seems you are arguing while having little idea of the implementation of what you are talking about. Order of items in the feed doesn't have anything to do with this discussion. > 2. Can't be done on atom:updated alone (unless you > accept that all > minor-changed version are equivalent to the first). > Can be done with > atom:modified. Republishers shouldn't be changing > the dates. Aggregators don't need atom:updated to know they have the most recent version of the feed since they just fetched it. atom:updated is merely a *hint* that change should be indicated to the user. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Oct 29 12:58: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 MAA15398 for ; Fri, 29 Oct 2004 12:58:05 -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 i9TGppcT076959; Fri, 29 Oct 2004 09:51:51 -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 i9TGppVD076958; Fri, 29 Oct 2004 09:51:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TGpocP076948 for ; Fri, 29 Oct 2004 09:51:50 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so81165rnb for ; Fri, 29 Oct 2004 09:51:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Biw4mf/0TDM8e67Dk7JKyACTPgS9UdrVqiCgVwr3R01ffMhH7yTvEEFfjNOgCi1ROgay/cA+CfW6MhBu7/wn5IAwRlMe9uD2AYG6WZmAUC4lWjcM3XLOkneJpWxZvavNfCnNv4fCNvyjGNYG/KSkVSUUEFWM3TzzuM2RZYz8qac= Received: by 10.38.98.30 with SMTP id v30mr365266rnb; Fri, 29 Oct 2004 09:51:44 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 09:51:43 -0700 (PDT) Message-ID: <1f2ed5cd0410290951640abf6e@mail.gmail.com> Date: Fri, 29 Oct 2004 18:51:43 +0200 From: Danny Ayers Reply-To: Danny Ayers To: mint@franklinmint.fm Subject: Re: PaceDateModified Cc: Dare Obasanjo , "Roger B." , Atom Syntax In-Reply-To: <41826E78.6000207@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <540e373204102908437072d80@mail.gmail.com> <20041029160224.46570.qmail@web40826.mail.yahoo.com> <1f2ed5cd041029090834fd517d@mail.gmail.com> <41826E78.6000207@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit atom:updated is for [[ ...a change to the feed was made that the publisher wishes to bring_to_the_attention_of_subscribers. ]] (my underscoring) Publisher side: "I sure hope your aggregator doesn't alert you every time I realize there's a spelling or grammatical error in something I've written." Consumer side: "I'll update the date field of the post." My, this must be a record for how soon a spec can be ignored... Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 13:08:16 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 NAA16213 for ; Fri, 29 Oct 2004 13:08:15 -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 i9TH1bMP082699; Fri, 29 Oct 2004 10:01:37 -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 i9TH1b2P082698; Fri, 29 Oct 2004 10:01:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TH1aaM082689 for ; Fri, 29 Oct 2004 10:01:37 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so98713rnl for ; Fri, 29 Oct 2004 10:01:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GbkbbHAkD80zeR4oJqvAIVCM1O1D1XwYCv/Xid5B2Fac3NFOh12/IOee4GSwurzo8scXhjv3iUmDOe+3c7Zc0Hza1eVn+iB7qwQQxB7oGxhdUpD2d2OaoLWu6LzWyEOE/8Wl6kHueeFwVAzPXYLElZCnd2y8SXSwLTBIa72IvRU= Received: by 10.38.206.23 with SMTP id d23mr341048rng; Fri, 29 Oct 2004 10:01:37 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 10:01:37 -0700 (PDT) Message-ID: <1f2ed5cd04102910011696c255@mail.gmail.com> Date: Fri, 29 Oct 2004 19:01:37 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceDateModified Cc: bob@wyman.us, Graham Parks , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <20041029163445.38843.qmail@web40802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04102909215ab496c4@mail.gmail.com> <20041029163445.38843.qmail@web40802.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 29 Oct 2004 09:34:45 -0700 (PDT), Dare Obasanjo wrote: > It seems you are arguing while having little idea of > the implementation of what you are talking about. > Order of items in the feed doesn't have anything to do > with this discussion. Ok, I was only thinking as far as multiple versions of an entry in a single feed document. Now that you mention it, there's nothing to say that more recently published feeds will contain the more recent entries. Another assumption that isn't found in the spec. > > 2. Can't be done on atom:updated alone (unless you > > accept that all > > minor-changed version are equivalent to the first). > > Can be done with > > atom:modified. Republishers shouldn't be changing > > the dates. > > Aggregators don't need atom:updated to know they have > the most recent version of the feed since they just > fetched it. The problem is at entry level. > atom:updated is merely a *hint* that change should be > indicated to the user. It states that the publisher wishes to bring the change to the user's attention. Sure, the aggregator can ignore the publisher's wishes. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 13:15:48 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 NAA16641 for ; Fri, 29 Oct 2004 13:15:47 -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 i9THAeCI089124; Fri, 29 Oct 2004 10:10: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 i9THAeDu089123; Fri, 29 Oct 2004 10:10:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THAev3089112 for ; Fri, 29 Oct 2004 10:10:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so69966rnk for ; Fri, 29 Oct 2004 10:10:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=D2/GzQGDjZWF69FkPL1YA+mybrENYAmlBeKd1s457YowRQji2oAKXJniKZEoF8ElhyyE59bodBeZqHhjD8qijRmBq4BitnO2RctR5lcnehokkPVbf7RJB+Ib+6j5tR1Efp+gUfo5IK5qHMtBFag4DNrCVQBehxuNwt7gdkJSE+A= Received: by 10.38.8.65 with SMTP id 65mr344500rnh; Fri, 29 Oct 2004 10:10:36 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Fri, 29 Oct 2004 10:10:36 -0700 (PDT) Message-ID: <1f2ed5cd041029101049149cc6@mail.gmail.com> Date: Fri, 29 Oct 2004 19:10:36 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Dare Obasanjo Subject: Re: PaceDateModified Cc: bob@wyman.us, Graham Parks , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <1f2ed5cd04102910011696c255@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd04102909215ab496c4@mail.gmail.com> <20041029163445.38843.qmail@web40802.mail.yahoo.com> <1f2ed5cd04102910011696c255@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ok, I'm pulling out of this discussion. I anticipate atom:modified will be ditched, ugly kludges will happen and atom:modified or something similar will reappear in a later version of the spec. But I would hope that the two use cases I presented (Norm's entries from multiple sources, a CMS used for software doc publication) are at least considered, and Bob's earlier question is answered satisfactorily, especially the bits around: [[ I should not be concerned with identifying the "latest" version since any version that shares the same atom:updated value is equivalent in the opinion of the publisher. The opinion of the publisher is paramount in these issues. ]] Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri Oct 29 13:25: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 NAA17271 for ; Fri, 29 Oct 2004 13:25: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 i9THIGRI093390; Fri, 29 Oct 2004 10:18: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 i9THIGFf093389; Fri, 29 Oct 2004 10:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9THIFOd093380 for ; Fri, 29 Oct 2004 10:18:16 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9THHhq5004236; Fri, 29 Oct 2004 13:18:13 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWQ67812 (AUTH bob@wyman.us); Fri, 29 Oct 2004 13:17:31 -0400 (EDT) Message-Id: <200410291717.BWQ67812@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" Cc: "'Atom Syntax'" Subject: RE: PaceDateModified Date: Fri, 29 Oct 2004 13:17:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS90R+lyWeH81w5Teu6oZEOciEd/AACNoQA In-Reply-To: <41824C4C.7040900@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Using Robert Sayre's example (slightly modified): T1: Title: "I love HTLM!" [Atom:updated set] T2: Title: "I love HTML!" T3: Title: "I love Atom!" [Atom:updated modified] Should PubSub forward 2 or 3 instances of this entry? Should we publish the entry published at T2 that is "modified" but does not change the atom:updated value? At some time T4, after T3, should a retrospective search engine like Feedster or Google return 1, 2 or 3 results given this stream of entries? If you argue that a retrospective search engine should only deliver 1 or 2 results at T4, then which result should be returned at some time T2.5 which is after T2 yet before T3? Should it return the first version of the entry or the second? I realize that all behaviors might be user definable or modified on request. My question concerns the *default* expected behavior. What is the "ideal" behavior? bob wyman From owner-atom-syntax@mail.imc.org Fri Oct 29 13: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 NAA19509 for ; Fri, 29 Oct 2004 13: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 i9THkgaa008259; Fri, 29 Oct 2004 10:46:43 -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 i9THkgNs008258; Fri, 29 Oct 2004 10:46:42 -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 i9THkguO008247 for ; Fri, 29 Oct 2004 10:46:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNapj-0006ir-6S; Fri, 29 Oct 2004 17:46:39 +0000 Message-ID: <418281FE.5060201@franklinmint.fm> Date: Fri, 29 Oct 2004 13:46:38 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: =?ISO-8859-1?Q?=27Bill_de_h=D3ra=27?= , "'Atom Syntax'" Subject: Re: PaceDateModified References: <200410291717.BWQ67812@ms8.netsolmail.com> In-Reply-To: <200410291717.BWQ67812@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Using Robert Sayre's example (slightly modified): > > T1: Title: "I love HTLM!" [Atom:updated set] > T2: Title: "I love HTML!" > T3: Title: "I love Atom!" [Atom:updated modified] > > Should PubSub forward 2 or 3 instances of this entry? Should we publish the > entry published at T2 that is "modified" but does not change the > atom:updated value? > > I realize that all behaviors might be user definable or modified on request. > My question concerns the *default* expected behavior. What is the "ideal" > behavior? 3 instances. It's data on the web. It's not a protocol. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 14:09:36 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 OAA20693 for ; Fri, 29 Oct 2004 14:09: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 i9THutvG013550; Fri, 29 Oct 2004 10:56: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 i9THutZ7013549; Fri, 29 Oct 2004 10:56:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40804.mail.yahoo.com (web40804.mail.yahoo.com [66.218.78.181]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9THusfX013484 for ; Fri, 29 Oct 2004 10:56:54 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029175653.94131.qmail@web40804.mail.yahoo.com> Received: from [131.107.71.226] by web40804.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 10:56:53 PDT Date: Fri, 29 Oct 2004 10:56:53 -0700 (PDT) From: Dare Obasanjo Subject: RE: PaceDateModified To: bob@wyman.us, mint@franklinmint.fm, "'Bill de \"hÓra'\"" Cc: "'Atom Syntax'" In-Reply-To: <200410291717.BWQ67812@ms8.netsolmail.com> 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: --- Bob Wyman wrote: > > Using Robert Sayre's example (slightly modified): > > T1: Title: "I love HTLM!" [Atom:updated set] > T2: Title: "I love HTML!" > T3: Title: "I love Atom!" [Atom:updated modified] > > Should PubSub forward 2 or 3 instances of this > entry? Should we publish the > entry published at T2 that is "modified" but does > not change the > atom:updated value? > > At some time T4, after T3, should a retrospective > search engine like > Feedster or Google return 1, 2 or 3 results given > this stream of entries? A search engine should cache the most recent version of the page. Period. That's what Feedster and every aggregator I've seen does today. This concept of 'change to content that is not significant enough to be cached' is a bogus notion that should not be encouraged. I fail to see how you drew the conclusion from the current discussion that you should do otherwise. Your question is like asking what Google should do if they fetch a page at time T3 and it has a Last-Modified date of T2 then when they fetch it at time T4 it has a Last-Modified date of T1. Should they throw away the version they fetched previously, keep it or keep both? Google and evey other search engine that implements caching has already solved this problem one way or the other today. I don't see why Atom has to reinvent the wheel. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Fri Oct 29 14:10:22 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 OAA20804 for ; Fri, 29 Oct 2004 14:10:22 -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 i9TI4hOd017520; Fri, 29 Oct 2004 11:04:43 -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 i9TI4hPD017519; Fri, 29 Oct 2004 11:04:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TI4gxR017452 for ; Fri, 29 Oct 2004 11:04:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.185] (tve9ba6e.brookes.ac.uk [161.73.18.185]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9THp9Ce018422; Fri, 29 Oct 2004 18:51:11 +0100 (BST) Message-ID: <4182830E.3040402@mac.com> Date: Fri, 29 Oct 2004 18:51:10 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid , atom Syntax Subject: Re: PaceDateModified References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Those scenarios are all valid, except they have nothing to do with Atom or syndication. Let's go back to your example of a client retrieving an old version of a feed from a cache, after retrieving the current one. The optimization here is "I've been accidentally sent an old version of this entry, I won't bother processing it further". I don't think that's going to buy anyone much, especially as the XML and date parsing is already done at that point. When else is it useful for optimizing? Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 14:20:28 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 OAA21240 for ; Fri, 29 Oct 2004 14:20:27 -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 i9TIDhmC021826; Fri, 29 Oct 2004 11:13:43 -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 i9TIDhkV021825; Fri, 29 Oct 2004 11:13:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TIDgmg021767 for ; Fri, 29 Oct 2004 11:13:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.185] (tve9ba6e.brookes.ac.uk [161.73.18.185]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9THwisT020330; Fri, 29 Oct 2004 18:58:44 +0100 (BST) Message-ID: <418284D6.2070402@mac.com> Date: Fri, 29 Oct 2004 18:58:46 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roger B." CC: Danny Ayers , Atom Syntax Subject: Re: PaceDateModified References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> In-Reply-To: <540e373204102908437072d80@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger B. wrote: > Put them both together and it suggests that the data you're looking > for will probably end up in atom:updated. In practical terms, > atom:updated is simply a version of atom:modified that gives the > publisher the option *not* to indicate a change. If they do that, they'd only be compliant with the spec if their intention was "YOU MUST SEE THIS SPELLING CORRECTION". I'd hope what they'd do is put the plain publishing date in there, ie atom:issued, and have it never change. (FYI: "The "atom:updated" element is a Date construct indicating the most recent instant in time when a change to the entry was made that the publisher wishes to bring to the attention of subscribers.") Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 14:51:43 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 OAA23604 for ; Fri, 29 Oct 2004 14:51:42 -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 i9TIimLu038449; Fri, 29 Oct 2004 11:44: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 i9TIimjM038448; Fri, 29 Oct 2004 11:44:48 -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 i9TIilp0038412 for ; Fri, 29 Oct 2004 11:44:47 -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 1CNbjw-0008WD-2f; Fri, 29 Oct 2004 18:44:44 +0000 Message-ID: <41828F9B.5090205@franklinmint.fm> Date: Fri, 29 Oct 2004 14:44:43 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: "Roger B." , Danny Ayers , Atom Syntax Subject: Re: PaceDateModified References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> <418284D6.2070402@mac.com> In-Reply-To: <418284D6.2070402@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > > Roger B. wrote: > >> Put them both together and it suggests that the data you're looking >> for will probably end up in atom:updated. In practical terms, >> atom:updated is simply a version of atom:modified that gives the >> publisher the option *not* to indicate a change. > > > If they do that, they'd only be compliant with the spec if their > intention was "YOU MUST SEE THIS SPELLING CORRECTION". That's not my interpretation of the spec. atom:updated means that a change occurred that publisher wishes to record (aka "bring to the attention of subscribers"). It doesn't communicate anything about the urgency of the change. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 15:15: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 PAA26430 for ; Fri, 29 Oct 2004 15:15: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 i9TJ80XN049852; Fri, 29 Oct 2004 12:08:00 -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 i9TJ80Ze049851; Fri, 29 Oct 2004 12:08:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40828.mail.yahoo.com (web40828.mail.yahoo.com [66.218.92.75]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9TJ7x9G049807 for ; Fri, 29 Oct 2004 12:08:00 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041029190759.33454.qmail@web40828.mail.yahoo.com> Received: from [131.107.76.30] by web40828.mail.yahoo.com via HTTP; Fri, 29 Oct 2004 12:07:59 PDT Date: Fri, 29 Oct 2004 12:07:59 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Graham Parks , "Roger B." Cc: Danny Ayers , Atom Syntax In-Reply-To: <418284D6.2070402@mac.com> 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: --- Graham Parks wrote: > If they do that, they'd only be compliant with the > spec if their > intention was "YOU MUST SEE THIS SPELLING > CORRECTION". I'd hope what > they'd do is put the plain publishing date in there, > ie atom:issued, and > have it never change. Ummm, if the publisher did not expect subscribers to pick up the changes in the typo then what exactly is the point of fixing the typo? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-atom-syntax@mail.imc.org Fri Oct 29 15:26:19 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 PAA28073 for ; Fri, 29 Oct 2004 15:26:19 -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 i9TJJ7aq055891; Fri, 29 Oct 2004 12:19:07 -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 i9TJJ7rM055890; Fri, 29 Oct 2004 12:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJJ6ex055815 for ; Fri, 29 Oct 2004 12:19:06 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.185] (tve9ba6e.brookes.ac.uk [161.73.18.185]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TIsnv1006730; Fri, 29 Oct 2004 19:54:54 +0100 (BST) Message-ID: <418291FB.8010503@mac.com> Date: Fri, 29 Oct 2004 19:54:51 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax Subject: Re: PaceDateModified References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> <418284D6.2070402@mac.com> <41828F9B.5090205@franklinmint.fm> In-Reply-To: <41828F9B.5090205@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > wishes to record (aka "bring to the attention of subscribers") How are these at all synonymous? The spec explicitly says that changes occuring at the same time as a change of atom:updated are meant to be brought to the attention of the user. A publisher that used Last Modified as atom:updated would be saying "I want my subscribers to be shown I've corrected that typo". Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 15:35:24 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 PAA28723 for ; Fri, 29 Oct 2004 15:35:23 -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 i9TJQLj1059810; Fri, 29 Oct 2004 12:26: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 i9TJQLVk059809; Fri, 29 Oct 2004 12:26:21 -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 i9TJQK7e059801 for ; Fri, 29 Oct 2004 12:26:20 -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 1CNcOD-0007VY-4u; Fri, 29 Oct 2004 19:26:21 +0000 Message-ID: <4182995E.4010205@franklinmint.fm> Date: Fri, 29 Oct 2004 15:26:22 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: Atom Syntax Subject: Re: PaceDateModified References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> <418284D6.2070402@mac.com> <41828F9B.5090205@franklinmint.fm> <418291FB.8010503@mac.com> In-Reply-To: <418291FB.8010503@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > Robert Sayre wrote: > >> wishes to record (aka "bring to the attention of subscribers") > > > How are these at all synonymous? > > The spec explicitly says that changes occuring at the same time as a > change of atom:updated are meant to be brought to the attention of the > user. A publisher that used Last Modified as atom:updated would be > saying "I want my subscribers to be shown I've corrected that typo". Are you saying that the date field implies some sort of interface behavior? If that's your definition, we should change it, because behavioral directives in data formats are evil. My interpretation of "bring to attention" is "record the date in the format, and transfer it to the subscriber". Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 15:43:38 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 PAA29453 for ; Fri, 29 Oct 2004 15:43:38 -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 i9TJacYi065324; Fri, 29 Oct 2004 12:36:38 -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 i9TJacHp065323; Fri, 29 Oct 2004 12:36:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJabR3065299 for ; Fri, 29 Oct 2004 12:36:37 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.185] (tve9ba6e.brookes.ac.uk [161.73.18.185]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TJFAf7012317; Fri, 29 Oct 2004 20:15:10 +0100 (BST) Message-ID: <418296C0.3050206@mac.com> Date: Fri, 29 Oct 2004 20:15:12 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dare Obasanjo CC: "Roger B." , Danny Ayers , Atom Syntax Subject: Re: PaceDateModified References: <20041029190759.33454.qmail@web40828.mail.yahoo.com> In-Reply-To: <20041029190759.33454.qmail@web40828.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > Ummm, if the publisher did not expect subscribers to > pick up the changes in the typo then what exactly is > the point of fixing the typo? Where did I say they shouldn't "pick up" the changes? Of course they should update their databases etc, and show the new version if the user selects the entry again, but atom:updated should only change if the publisher needs/wants to bring the changes to the user's attention. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 15:49: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 PAA00109 for ; Fri, 29 Oct 2004 15:49: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 i9TJhQGl067062; Fri, 29 Oct 2004 12:43:26 -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 i9TJhQOq067061; Fri, 29 Oct 2004 12:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJhP48067023 for ; Fri, 29 Oct 2004 12:43:25 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.18.185] (tve9ba6e.brookes.ac.uk [161.73.18.185]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9TJWl42016799; Fri, 29 Oct 2004 20:32:47 +0100 (BST) Message-ID: <41829ADF.1030809@mac.com> Date: Fri, 29 Oct 2004 20:32:47 +0100 From: Graham Parks User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm, atom Syntax Subject: Re: PaceDateModified References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> <418284D6.2070402@mac.com> <41828F9B.5090205@franklinmint.fm> <418291FB.8010503@mac.com> <4182995E.4010205@franklinmint.fm> In-Reply-To: <4182995E.4010205@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > My interpretation of "bring to attention" is "record the date in the > format, and transfer it to the subscriber". If that was what was meant, that's what it would say. "bring to the attention of subscribers" definitely implies much more than recording the change. This isn't a "behavioural directive". All it says is that the publisher would like to bring it the subscribers attention - there's no requirement for the UA to follow through. Graham From owner-atom-syntax@mail.imc.org Fri Oct 29 16:03:04 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 QAA01396 for ; Fri, 29 Oct 2004 16:03: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 i9TJtVdi069849; Fri, 29 Oct 2004 12:55:31 -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 i9TJtVf2069848; Fri, 29 Oct 2004 12:55:31 -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 i9TJtUJi069828 for ; Fri, 29 Oct 2004 12:55:30 -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 1CNcqR-0004EO-HZ; Fri, 29 Oct 2004 19:55:31 +0000 Message-ID: <4182A033.5070409@franklinmint.fm> Date: Fri, 29 Oct 2004 15:55:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Parks CC: atom Syntax Subject: Re: PaceDateModified References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> <418284D6.2070402@mac.com> <41828F9B.5090205@franklinmint.fm> <418291FB.8010503@mac.com> <4182995E.4010205@franklinmint.fm> <41829ADF.1030809@mac.com> In-Reply-To: <41829ADF.1030809@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > > Robert Sayre wrote: > >> My interpretation of "bring to attention" is "record the date in the >> format, and transfer it to the subscriber". > > > If that was what was meant, that's what it would say. "bring to the > attention of subscribers" definitely implies much more than recording > the change. > > This isn't a "behavioural directive". All it says is that the publisher > would like to bring it the subscribers attention - there's no > requirement for the UA to follow through. Then it doesn't mean "YOU MUST SEE THIS SPELLING CORRECTION" does it? "Bring to the attention of subscribers" is bogus language. I'll write a Pace to get it out of there. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 16:03: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 QAA01419 for ; Fri, 29 Oct 2004 16:03: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 i9TJmFlH068079; Fri, 29 Oct 2004 12:48: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 i9TJmFeF068078; Fri, 29 Oct 2004 12:48:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJmEkV068063 for ; Fri, 29 Oct 2004 12:48:14 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@ms8.netsolmail.com [216.168.230.180] (may be forged)) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9TJlU25021548; Fri, 29 Oct 2004 15:47:31 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWR04928 (AUTH bob@wyman.us); Fri, 29 Oct 2004 15:47:29 -0400 (EDT) Message-Id: <200410291947.BWR04928@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Dare Obasanjo'" , , , "''Bill de \"hXra'\"'" Cc: "'Atom Syntax'" Subject: RE: PaceDateModified Date: Fri, 29 Oct 2004 15:47:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS947xxgdz7RyRXQEK4MCjddY4yRQACk3Pw In-Reply-To: <20041029175653.94131.qmail@web40804.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: > A search engine should cache the most recent version of the page. > Period. That's what Feedster and every aggregator I've seen does today. Right. But, there are some issues in determining what is the "most recent version of the page" in some environments *if* dissimilar versions published or retrieved at different times can share common atom:updated values. > This concept of 'change to content that is not significant enough to be > cached' is a bogus notion that should not be encouraged. I fail to see > how you drew the conclusion from the current discussion that you should > do otherwise. The current draft empowers the publisher with a means for indicating that "a change to the feed was made that the publisher wishes to bring to the attention of subscribers." There is an implication here that if the publisher does *not* change the atom:updated value, then the publisher "does not wish to bring this change to the attention of subscribers." If the publisher does not wish attention to be drawn to the change, then why would aggregators, in-channel intermediaries, search-engines, etc. process the change? Why are we providing mechanisms to make it easier for publishers to publish data that they don't care if anyone reads? Personally, I think that the atom:updated is simply too confusing and should be replaced by the much simpler and more easily understood atom:modified. I am not convinced that there are a usefully large number of cases in which the publisher will change and republish an entry yet not wish to "bring this change to the attention of subscribers." It seems to me that we've made a mistake by first adopting atom:updated, an edge case solution, when we should have first adopted atom:modified and then had folk try to justify why atom:updated should be in the core rather than in an extension. The debate so far indicates that if atom:updated remains in the core, we'll be suffering through debates about the meaning and implications of "significant change" for the next few decades... A new perma-thread has been born... Not all births should be celebrated... bob wyman From owner-atom-syntax@mail.imc.org Fri Oct 29 16:14: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 QAA02706 for ; Fri, 29 Oct 2004 16:13:59 -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 i9TK7f65073553; Fri, 29 Oct 2004 13:07: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 i9TK7fi3073552; Fri, 29 Oct 2004 13:07:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TK7evj073512 for ; Fri, 29 Oct 2004 13:07:40 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so1126437wri for ; Fri, 29 Oct 2004 13:07:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=njzKydt/AY6GGlrIyplwTtg4qhIDmq3GQsVk50MmH8+2CQcGhv2XxJrPH7N2/RpGi8NvwbexSJvp7FoF1FuqDhsLmnm0NYsTCEo6XrThyek4/dsSCDKTT25asVkk/1eNnAJ+2Gbpwj01ufeTKq7uM8dU0Q/xdvp7nELKQNVdiXU= Received: by 10.38.209.71 with SMTP id h71mr3132102rng; Fri, 29 Oct 2004 13:07:34 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Fri, 29 Oct 2004 13:07:34 -0700 (PDT) Message-ID: <540e3732041029130737d52d2d@mail.gmail.com> Date: Fri, 29 Oct 2004 15:07:34 -0500 From: "Roger B." Reply-To: "Roger B." To: Graham Parks Subject: Re: PaceDateModified Cc: Atom Syntax In-Reply-To: <418296C0.3050206@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041029190759.33454.qmail@web40828.mail.yahoo.com> <418296C0.3050206@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > atom:updated should only change if the > publisher needs/wants to bring the changes to the user's attention. Graham: Assuming atom:updated is the sole "changed" date in the Atom core, I suspect many publishers will decide that it's better to bring all changes to the user's attention than none. That's certainly what I'd be inclined to do when putting together a default Atom template. Personally, I think we'd be better off with an "atom:entry must contain a 'changed' date, either atom:modified or atom:updated" rule than make either of them mandatory to the exclusion of the other. But we've already approved updated as a required element, and modified has little traction... so look for the former to be used like the latter. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Oct 29 16:52:16 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 QAA10600 for ; Fri, 29 Oct 2004 16:52:15 -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 i9TKiZg1080846; Fri, 29 Oct 2004 13:44:35 -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 i9TKiZXD080843; Fri, 29 Oct 2004 13:44:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKiXJK080812 for ; Fri, 29 Oct 2004 13:44:34 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9TKicui007407 for ; Fri, 29 Oct 2004 14:44:38 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D00ELE5MDGJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:38 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:37 -0600 (MDT) Date: Fri, 29 Oct 2004 11:37:43 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: <200410291543.BWQ46569@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Graham Parks'" , "=?ISO-8859-1?Q?'Bill_de_h=D3ra'?=" , "'Atom Syntax'" Message-id: <9EA3EF7C-29D9-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200410291543.BWQ46569@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 29, 2004, at 8:42 AM, Bob Wyman wrote: > If atom:updated is used to flag only those changes that the author > of an entry wishes to bring to the attention of readers, then it seems > to me > that intermediaries should respect the publisher's statements and > ignore any > updates that are not so flagged. If this is correct, then any change > detection on the part of intermediaries should be considered a bad > thing. > Intermediaries should not be generating entry hashes or otherwise > trying to > detect changes. It depends whether you trust the publisher. If not, it's entirely appropriate to go ahead and ignore dates and do data-level comparison. But if not, it's inappropriate to trust atom:modified when you don't trust atom:updated. > The model seems to be that an aggregator needs to build a database > of entries that has columns for atom:id and atom:updated. I should > then only > process those entries that have atom:updated values that are greater > then > what was previously stored for any given atom:id. No matter how great > the > difference may be between two versions of an entry, I should not pay > any > attention to the difference unless explicitly "told to" by a new > atom:updated value. That's how I'd do it. > This implies that if I find multiple versions of an entry, I should > ignore all but the *first* instance of an entry found with any > particular > atom:updated value. I should not be concerned with identifying the > "latest" > version since any version that shares the same atom:updated value is > equivalent in the opinion of the publisher. The opinion of the > publisher is > paramount in these issues. Unless, of course, you distrust the publisher, in which case you should ignore each and every date field and draw your own conclusions. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 16:52:16 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 QAA10602 for ; Fri, 29 Oct 2004 16:52:16 -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 i9TKisVg080941; Fri, 29 Oct 2004 13:44:54 -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 i9TKislM080936; Fri, 29 Oct 2004 13:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKipku080900 for ; Fri, 29 Oct 2004 13:44:51 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TKisNH026763 for ; Fri, 29 Oct 2004 14:44:54 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D002HA5MT61@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:54 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:39 -0600 (MDT) Date: Fri, 29 Oct 2004 11:31:54 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 29, 2004, at 5:44 AM, Eric Scheid wrote: > Without atom:modified, such changes might well never propagate through > systems, even if more recently retrieved. Which, doesn't matter, unless you've decided you don't trust the publisher's choice in setting atom:updated. In which case, you probably shouldn't trust their truthfulness setting atom:modified either. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 16:52: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 QAA10622 for ; Fri, 29 Oct 2004 16:52: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 i9TKiZNS080853; Fri, 29 Oct 2004 13:44:35 -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 i9TKiZWu080852; Fri, 29 Oct 2004 13:44:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKiYEC080813 for ; Fri, 29 Oct 2004 13:44:34 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9TKicui007413 for ; Fri, 29 Oct 2004 14:44:38 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D00ELE5MDGJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:38 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:37 -0600 (MDT) Date: Fri, 29 Oct 2004 11:34:54 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: <540e373204102908437072d80@mail.gmail.com> To: "Roger B." Cc: Atom Syntax , Danny Ayers Message-id: <3A3BBA94-29D9-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <76ACFBED7878B8FCC4E2E054@10.238.0.81> <1f2ed5cd041029075694ee80d@mail.gmail.com> <540e373204102908437072d80@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 29, 2004, at 8:43 AM, Roger B. wrote: > Put them both together and it suggests that the data you're looking > for will probably end up in atom:updated. In practical terms, > atom:updated is simply a version of atom:modified that gives the > publisher the option *not* to indicate a change. Exactly. Mind you, people could lie with atom:modified too. Filthy creatures, publishers. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 16:52: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 QAA10619 for ; Fri, 29 Oct 2004 16:52:16 -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 i9TKisL8080943; Fri, 29 Oct 2004 13:44:54 -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 i9TKisq1080938; Fri, 29 Oct 2004 13:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKippw080902 for ; Fri, 29 Oct 2004 13:44:51 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TKitNH026789 for ; Fri, 29 Oct 2004 14:44:55 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D002HA5MT61@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:55 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:40 -0600 (MDT) Date: Fri, 29 Oct 2004 11:28:30 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: <55506F0C-29D8-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 28, 2004, at 6:21 PM, Eric Scheid wrote: >> How about if I change the stylesheet? In a material way? In a way >> that's >> unnoticeable except for it fixes a bug in the latest Safari release? >> How >> about if I change only the serif version of the stylesheet, leaving >> sans-serif >> untouched? > > Is the stylesheet content actually in the atom entry, or is it > referenced > from there? If it's external, then it has it's own http:last-modified > value. My point is that as the publisher, I can look at what I'm doing to the stylesheet or normalization and make up my mind whether it's important enough to consider an update. There is no automatic decision procedure ("objective", feh) that can meaningfully define what constitutes an update. Per your argument, if I drastically changed the *external* stylesheet in a way that I thought mandated re-reading the content, I should change atom:updated, but not change atom:modified, because the content itself hadn't changed. ???? -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 16:52: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 QAA10736 for ; Fri, 29 Oct 2004 16:52:50 -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 i9TKisSc080939; Fri, 29 Oct 2004 13:44:54 -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 i9TKismr080932; Fri, 29 Oct 2004 13:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKip51080903 for ; Fri, 29 Oct 2004 13:44:51 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9TKitui007621 for ; Fri, 29 Oct 2004 14:44:55 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D002HA5MT61@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:55 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:41 -0600 (MDT) Date: Fri, 29 Oct 2004 11:26:00 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 28, 2004, at 6:21 PM, Eric Scheid wrote: > Why? When you two versions of the same entry, and they both have the > same > atom:updated value, yet they are different in content. How do you > determine > which is the most recently modified? You could assume that if it mattered, the publisher would have changed atom:updated, and not stress out; just pick whichever you picked up most recently. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 16:53: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 QAA10784 for ; Fri, 29 Oct 2004 16:53:29 -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 i9TKis8I080940; Fri, 29 Oct 2004 13:44:54 -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 i9TKisXK080934; Fri, 29 Oct 2004 13:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKipk3080899 for ; Fri, 29 Oct 2004 13:44:51 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TKisNH026753 for ; Fri, 29 Oct 2004 14:44:54 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D002HA5MT61@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:53 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:39 -0600 (MDT) Date: Fri, 29 Oct 2004 11:33:51 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: <145ADD3D-29D9-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 29, 2004, at 8:04 AM, Eric Scheid wrote: > Changes in atom:modified tell us (1) something has changed, without > having > to try to spot the change amongst the XML serialisation, and (2) which > of > the two versions is the more recent. Only if you trust atom:modified. But you've already decided not to trust atom:updated, so why should you? -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 17:04:29 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 RAA11664 for ; Fri, 29 Oct 2004 17:04:28 -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 i9TKis85080942; Fri, 29 Oct 2004 13:44:54 -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 i9TKisVd080933; Fri, 29 Oct 2004 13:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKipfd080901 for ; Fri, 29 Oct 2004 13:44:51 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TKisNH026772 for ; Fri, 29 Oct 2004 14:44:55 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D002HA5MT61@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:54 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0004T5M8KP@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:44:40 -0600 (MDT) Date: Fri, 29 Oct 2004 11:30:26 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: <200410290231.BWP02800@ms8.netsolmail.com> To: Bob Wyman Cc: "'Danny Ayers'" , "'Sam Ruby'" , mint@franklinmint.fm, atom-syntax@imc.org Message-id: <9A71F7F2-29D8-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200410290231.BWP02800@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 28, 2004, at 7:31 PM, Bob Wyman wrote: > > Sam Ruby wrote: >> FYI: Mod speedyfeed[1] makes use of the atom:modified element. > I think that in general, most implementations of RFC3229+feed[2] > would also want to atom:modified available to them. Only on the assumption that you had made a deliberate policy decision to ignore the expressed opinion of the publisher as to when the content had meaningfully changed. In which case, you have to acknowledge that a publisher might choose to lie about atom:modified to. In which case, to be sure, you have to compare the content. In which case, there is no case for atom:modified. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 17:13:38 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 RAA12817 for ; Fri, 29 Oct 2004 17:13:37 -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 i9TKxB3r083574; Fri, 29 Oct 2004 13:59:11 -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 i9TKxBnb083572; Fri, 29 Oct 2004 13:59:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKxAtc083564 for ; Fri, 29 Oct 2004 13:59:11 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9TKxFNH003778 for ; Fri, 29 Oct 2004 14:59:15 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6D00EC86AQGJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:59:15 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6D0008J6AQKK@mail.sun.net> for atom-syntax@imc.org; Fri, 29 Oct 2004 14:59:14 -0600 (MDT) Date: Fri, 29 Oct 2004 13:59:56 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: <20041029190759.33454.qmail@web40828.mail.yahoo.com> To: Dare Obasanjo Cc: "Roger B." , Atom Syntax , Danny Ayers , Graham Parks Message-id: <7D067C3B-29ED-11D9-9F4E-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041029190759.33454.qmail@web40828.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 29, 2004, at 12:07 PM, Dare Obasanjo wrote: > Ummm, if the publisher did not expect subscribers to > pick up the changes in the typo then what exactly is > the point of fixing the typo? You don't feel it's worth suggesting that subscribers who read it should re-read, but you'd like people who pick it up in future not to have to read around the typo. I do this all the time on 'ongoing'. -Tim From owner-atom-syntax@mail.imc.org Fri Oct 29 19:04:24 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 TAA24044 for ; Fri, 29 Oct 2004 19:04:24 -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 i9TMqofF007502; Fri, 29 Oct 2004 15:52: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 i9TMqoJg007501; Fri, 29 Oct 2004 15:52:50 -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 i9TMqnWI007489 for ; Fri, 29 Oct 2004 15:52:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNfbz-0004in-VL for atom-syntax@imc.org; Fri, 29 Oct 2004 22:52:48 +0000 Message-ID: <4182C9C0.1000600@franklinmint.fm> Date: Fri, 29 Oct 2004 18:52:48 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceUpdatedDefinition 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 Hi all, Another Date-related Pace. Yay! None of the verbs or nouns in the phrase "bring to the attention of subscribers" are defined in the spec, so we managed to reach consensus on atom:updated without reaching consensus. This is a proposed clarification/alteration/crusher-of-dreams. Choose your favorite description. Robert Sayre Abstract ------------------- Alter the definition of atom:updated. Status ------------------- Open Supporters ------------------- RobertSayre Rationale ------------------- The definition of atom:updated is confusing, and causes rational people to disagree on its purpose. The phrase "bring to the attention of subscribers" is inadequate, as it depends entirely on the definition of terms. Undefined terms: * "Bring" * "Attention" * "Subscribers" (we use "producer", "consumer", and "processor"... this is a new one) Proposal ------------------- Replace the first paragraph of the current definitions of atom:updated with the following: The "atom:updated" element is a Date construct indicating the most recent instant in time when a substantive modification to the [feed/entry] was made. The value of atom:updated can be changed at the producer's discretion. ------------------- Robert Sayre From owner-atom-syntax@mail.imc.org Fri Oct 29 19:28: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 TAA25637 for ; Fri, 29 Oct 2004 19:28: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 i9TNLFnq012565; Fri, 29 Oct 2004 16:21: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 i9TNLFSb012564; Fri, 29 Oct 2004 16:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TNLDHJ012545 for ; Fri, 29 Oct 2004 16:21:14 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Fri, 29 Oct 2004 16:21:15 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: No consensus on PaceDateModified Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wearing my co-chair hat, I am going to declare non-consensus on PaceDateModified. (Friday afternoon is a good time to state the obvious.) There are plenty of different people with different technical objections to it. It's time for the WG to move on to the other items on the current work rotation: At 1:30 PM -0400 10/28/04, Sam Ruby wrote: >Making link not required (in some circumstances): > > PaceContentOrLink > PaceOptionalAlternateLink > >Error reporting: > > PaceErrVerb > PaceServiceError > >Host from mod-wiki: > > PacePersonConstructs > --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Oct 29 20:14:48 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 UAA28155 for ; Fri, 29 Oct 2004 20:14:48 -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 i9U05qiL019776; Fri, 29 Oct 2004 17:05: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 i9U05qS0019775; Fri, 29 Oct 2004 17:05:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U05ngj019642 for ; Fri, 29 Oct 2004 17:05:51 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 10:05:25 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 10:05:18 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4182668D.6030505@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 1:49 AM, "Robert Sayre" wrote: >> Are they planning on using atom:updated to signal typo changes? >> > > That's what I'll be doing. perhaps then the spec should be updated such that atom:updated is specced the way you want it - all changes get reflected in atom:updated. what we'll need then is some way of letting a publisher selectively signal that the change is qualitatively different from all the noisy changes which are minor trivialities of spelling fixes and the like. Something like atom:updated-significantly. seriously. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 20:30:28 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 UAA29202 for ; Fri, 29 Oct 2004 20:30:27 -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 i9U0O7ZU024872; Fri, 29 Oct 2004 17:24:07 -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 i9U0O7pi024871; Fri, 29 Oct 2004 17:24:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U0O6LF024864 for ; Fri, 29 Oct 2004 17:24:06 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 10:24:16 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 10:24:09 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20041029190759.33454.qmail@web40828.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 5:07 AM, "Dare Obasanjo" wrote: > Ummm, if the publisher did not expect subscribers to > pick up the changes in the typo then what exactly is > the point of fixing the typo? Didn't I already ask that? Fact is, it seems people do like to fix typos. I use the diffs function in NNW, and while I do see lots of posts with significant updates, I also see lots of posts where dumb quotes get smarty, typos get fixed, egregious line breaks removed, etc, etc, etc. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 20:46:16 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 UAA00248 for ; Fri, 29 Oct 2004 20:46:16 -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 i9U0cMDH026826; Fri, 29 Oct 2004 17:38:22 -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 i9U0cMYq026825; Fri, 29 Oct 2004 17:38:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U0cLBI026810 for ; Fri, 29 Oct 2004 17:38:22 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 10:38:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 10:38:25 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <55506F0C-29D8-11D9-9F4E-000A95A51C9E@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 4:28 AM, "Tim Bray" wrote: > Per your argument, if I drastically changed the *external* > stylesheet in a way that I thought mandated re-reading the content, I > should change atom:updated, but not change atom:modified, because the > content itself hadn't changed. atom:updated is part of the entry. it has changed. ergo, atom:modified should also be changed in this use case. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 21:01: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 VAA01152 for ; Fri, 29 Oct 2004 21:01:05 -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 i9U0rdQw030540; Fri, 29 Oct 2004 17:53:39 -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 i9U0rdIs030538; Fri, 29 Oct 2004 17:53:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U0rcfV030529 for ; Fri, 29 Oct 2004 17:53:38 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 30 Oct 2004 10:53:48 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 30 Oct 2004 10:53:42 +1000 Subject: Re: PaceUpdatedDefinition From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4182C9C0.1000600@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 8:52 AM, "Robert Sayre" wrote: > The "atom:updated" element is a Date construct indicating the most > recent instant in time when a substantive modification to the > [feed/entry] was made. The value of atom:updated can be changed at > the producer's discretion. define 'substantive'. in the spirit of writing spec text, I suggest: For example, such changes might not include minor adjustments like spelling and grammatical corrections. e. From owner-atom-syntax@mail.imc.org Fri Oct 29 22:58: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 WAA06811 for ; Fri, 29 Oct 2004 22:58: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 i9U2l0Uk049201; Fri, 29 Oct 2004 19:47:00 -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 i9U2l0wR049198; Fri, 29 Oct 2004 19:47:00 -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 i9U2kr8I049144 for ; Fri, 29 Oct 2004 19:46:59 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004103002465401300c0uqde> (Authid: TimHare); Sat, 30 Oct 2004 02:46:54 +0000 Message-Id: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 29 Oct 2004 22:38:36 -0400 To: atom-syntax@imc.org From: TimHare@comcast.net Subject: A small suggestion for the Atom draft(s) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a suggestion to aid in the promotion and adoption of Atom, once the drafts are in a good spot. I feel it would be a good idea to include XSL transforms in the document that can transform Atom into the various flavors of RSS. This would aid some developers, who could put a "transform incoming Atom to RSS" wrapper around their existing RSS-based code by simply invoking an XSL processor with the appropriate stylesheet. This would allow developers to adopt a form "support" for Atom almost immediately, but allowing them more time to develop "native" support for Atom where they would exploit the richer metadata tags in Atom. I'm not an XML expert, but it seems to me that Atom tags contain everything you would need to create RSS via a simple template-based transformation. Tim Hare Interested Bystander, Non-Inc. From owner-atom-syntax@mail.imc.org Fri Oct 29 23:49: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 XAA10400 for ; Fri, 29 Oct 2004 23:48:59 -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 i9U3dGBT058266; Fri, 29 Oct 2004 20:39: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 i9U3dGVt058265; Fri, 29 Oct 2004 20:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.219] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U3dCVX058241; Fri, 29 Oct 2004 20:39:13 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> Date: Fri, 29 Oct 2004 20:39:15 -0700 To: TimHare@comcast.net, atom-syntax@imc.org From: Paul Hoffman / IMC Subject: Re: A small suggestion for the Atom draft(s) 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:38 PM -0400 10/29/04, TimHare@comcast.net wrote: >This is a suggestion to aid in the promotion and adoption of Atom, >once the drafts are in a good spot. I feel it would be a good idea >to include XSL transforms in the document that can transform Atom >into the various flavors of RSS. This would aid some developers, >who could put a "transform incoming Atom to RSS" wrapper around >their existing RSS-based code by simply invoking an XSL processor >with the appropriate stylesheet. This would allow developers to >adopt a form "support" for Atom almost immediately, but allowing >them more time to develop "native" support for Atom where they would >exploit the richer metadata tags in Atom. I'm not an XML expert, >but it seems to me that Atom tags contain everything you would need >to create RSS via a simple template-based transformation. This is not part of what we want to do with the Atom core, but it is certainly an interesting project for someone to do on their own. If you do it, by all means let the WG know! --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Oct 30 06:12: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 GAA12972 for ; Sat, 30 Oct 2004 06:12: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 i9U9v3Eq078599; Sat, 30 Oct 2004 02:57:03 -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 i9U9v3SN078597; Sat, 30 Oct 2004 02:57:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9U9v1GD078553 for ; Sat, 30 Oct 2004 02:57:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so93149rnk for ; Sat, 30 Oct 2004 02:57:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gioi/hLx5Iqg6Y+g7hMvGHu0qMf0dIOmCOX9jA13OxbsaGTMyR7vJCmZiaNAsC+h0TpwQLD1QmQr5ri+yToWDM7MSSflhVcAb0DHVTrDLR1Vco4qJeP3glHPfalgriA8f80ClIWfOM4wjj8Eyi6+M/CcwZbfC5PUcy2vsV/vw78= Received: by 10.38.8.65 with SMTP id 65mr659936rnh; Sat, 30 Oct 2004 02:57:02 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 02:57:02 -0700 (PDT) Message-ID: <1f2ed5cd0410300257371dafa1@mail.gmail.com> Date: Sat, 30 Oct 2004 11:57:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: eric.scheid@ironclad.net.au, mint@franklinmint.fm Subject: Re: PaceUpdatedDefinition Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4182C9C0.1000600@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [I'm back! I think rewording has a change of breaking the logjam] I like "typically" because it expresses the most common, expected case. Either: "such changes would typically not include minor adjustments like spelling and grammatical corrections." or "such changes would typically include minor adjustments like spelling and grammatical corrections." We may disagree on which, but the most important thing is to have everyone reading from the same page, no? I realise that we don't really want to put behaviour definitions into the spec, but it might help with the wording to imagine exactly what behaviour we would expect in a typical client - say RSS Bandit. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 06:15:13 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 GAA13072 for ; Sat, 30 Oct 2004 06:15:13 -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 i9UA9djd084282; Sat, 30 Oct 2004 03:09:39 -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 i9UA9dhL084281; Sat, 30 Oct 2004 03:09:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UA9cqs084270 for ; Sat, 30 Oct 2004 03:09:38 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so112819rnb for ; Sat, 30 Oct 2004 03:09:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=Z32lfouZJpp/ofqBBcXiUIXpG1cz/inS579Qn7Qxxr1584zuK8y+QjgG61DueStArRLir6H/rqx1Eq+t/7/Iuc/VucAy2D3YlKIrta/NCgeeOmGbdhGgnw08OkCEPWQhH0GzU/Zr06ShdD17U118iZCPZ7+QLsuirj/41JVVjbI= Received: by 10.38.98.30 with SMTP id v30mr691213rnb; Sat, 30 Oct 2004 03:09:38 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 03:09:38 -0700 (PDT) Message-ID: <1f2ed5cd04103003092878e381@mail.gmail.com> Date: Sat, 30 Oct 2004 12:09:38 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: DateSpecTests Cc: mint@franklinmint.fm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some semi-formal tests to help determine whether what's been specified for dates (PaceDateUpdated, PaceDateModified, PaceUpdatedDefinition) will work in practice. http://www.intertwingly.net/wiki/pie/DateSpecTests (sorry about the layout, the Wiki won't let me edit again) == Use Cases == How would the following be handled - Choosing latest entry from multiple feeds: http://www.imc.org/atom-syntax/mail-archive/msg10894.html Single feed for project documentation: http://www.imc.org/atom-syntax/mail-archive/msg10931.html === Analysis === Would Bob's analysis hold? - [[ This implies that if I find multiple versions of an entry, I should ignore all but the *first* instance of an entry found with any particular atom:updated value. I should not be concerned with identifying the "latest" version since any version that shares the same atom:updated value is equivalent in the opinion of the publisher. The opinion of the publisher is paramount in these issues. ]] http://www.imc.org/atom-syntax/mail-archive/msg10930.html === General Case === On atom-syntax: Danny: >> Are they planning on using atom:updated to signal typo changes? >> Robert: > That's what I'll be doing. Do you consider that typical or exceptional behaviour? -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 06:46:16 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 GAA14433 for ; Sat, 30 Oct 2004 06:46:15 -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 i9UAdeLG096191; Sat, 30 Oct 2004 03:39: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 i9UAdeVu096190; Sat, 30 Oct 2004 03:39:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UAdd0J096168 for ; Sat, 30 Oct 2004 03:39:40 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so113059rnb for ; Sat, 30 Oct 2004 03:39:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BiXIdrLowRmIbxFmpeF7R5s8kaqLQgZ3s28aBBVnpbKdFT39IpjZt5UqLWoTajksNRV3EiH5/OiAHW5CMUfc1oBszyy9zu3GNrlX3FeX+GsBTFwVJIyvZQzQqhsoiP1jPlMPC6wPCCRNB9VEP1O/paFGvGFXqw0YuqL/ECYCB8Q= Received: by 10.38.98.30 with SMTP id v30mr697664rnb; Sat, 30 Oct 2004 03:39:37 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 03:39:37 -0700 (PDT) Message-ID: <1f2ed5cd0410300339e651901@mail.gmail.com> Date: Sat, 30 Oct 2004 12:39:37 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org, timhare@comcast.net Subject: Re: A small suggestion for the Atom draft(s) Cc: henry.story@bblfish.net In-Reply-To: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I do think this is a good idea, and would hope to see something like this at least as informative material associated with the spec. I'd say it was closer to the core than Paul suggests, as the charter says: "The working group's primary focus will be on delivering an interoperable format and corresponding protocol..." Interop in the present environment means being able to bridge to RSS systems. XSLT should offer a good approach. Having said all that, > it seems to me that Atom tags contain everything you would > need to create RSS via a simple template-based transformation. It's definitely something that needs to be looked at in more detail, but I don't think this can be done right now - Atom => RSS 1.0 will almost certainly need extensions to the RSS (something which should come out of the work Henry and I have been doing with RDF/OWL) RSS 1.0 => Atom will be lossy, because of the lack of extension support in Atom (e.g. try a Nature feed: http://www.nature.com/rss) Atom => RSS 2.0 again will be lossy without extensions (for RSS), but the ambiguity around content markup means this will probably be indeterminate no matter what, so a usable hack is probably the best bet. RSS 2.0 => Atom should be most straightforward, assuming we find a good strategy for interpreting content with markup. RSS 0.9 is RDF/XML, so can be mapped as RSS 1.0. RSS 0.91 and the other 57 varieties are probably best considered as marginally invalid RSS 2.0. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 08:49:50 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 IAA21099 for ; Sat, 30 Oct 2004 08:49:47 -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 i9UCb8pi050230; Sat, 30 Oct 2004 05:37: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 i9UCb7nA050228; Sat, 30 Oct 2004 05:37:07 -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 i9UCb6Zh050118 for ; Sat, 30 Oct 2004 05:37:07 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id BF3E17C2E7; Sat, 30 Oct 2004 14:33:02 +0200 (CEST) Date: Sat, 30 Oct 2004 14:37:43 +0200 To: "Graham Parks" Subject: Re: PaceDateModified Cc: Atom-Syntax References: <4181E1BF.4070500@franklinmint.fm> <1f2ed5cd041029030079781412@mail.gmail.com> <418217DB.9040207@mac.com> <1f2ed5cd04102905097aa3219@mail.gmail.com> <41823505.4020106@mac.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <41823505.4020106@mac.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 29 Oct 2004 13:18:13 +0100, Graham Parks wrote: > Depends what you clicked on to get to it. If you clicked on a specific > feed to get to the entry, then obviousdly it would show the entry from > that feed. So I guess we're talking about an aggregated list of entries > (something I personally never use). Have you ever used USENET with a decent news reader? If so, you've probably noticed that all cross-posted messages is marked as «read» once for all newsgroups, based on their Message-ID. I'd say that the above-mentioned scenario is just the same; a cross-post of a single Atom article. Regardless of which feed, group, context or mood I read the single entry in, I would _not_ want to have it show up again whenever I change either of these variables. An entry is an entry is an entry, because it has the same atom:id. When I've read it, I've read it, and don't want to read it again. I'd say that's one of the main values in atom:id. But. I would like to read updates in the entry, and I would like to read the latest version of the entry if I haven't read it before. > The aggregator would then need to have functionality that removed > duplicates, based on id. Yes. > Because of the dangers of spoofing I'd imagine this would be off by > default. This is not off by default in news readers that supports supersede mechanisms. It's also not off to mark an article as read regardless of which group it's posted to. -- 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 Sat Oct 30 08:53:29 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 IAA21293 for ; Sat, 30 Oct 2004 08:53:29 -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 i9UCl3nQ055106; Sat, 30 Oct 2004 05:47:03 -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 i9UCl3Wa055105; Sat, 30 Oct 2004 05:47:03 -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 i9UCl2vI055052 for ; Sat, 30 Oct 2004 05:47:02 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id BAE5B7C1EE; Sat, 30 Oct 2004 14:43:05 +0200 (CEST) Date: Sat, 30 Oct 2004 14:47:46 +0200 To: "Dare Obasanjo" Subject: Re: PaceDateModified Cc: Atom-Syntax References: <20041029124447.14794.qmail@web40802.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20041029124447.14794.qmail@web40802.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 29 Oct 2004 05:44:47 -0700 (PDT), Dare Obasanjo wrote: > First of all this assumes the aggregator tracks items across different > feeds with the same ID. So far I haven't seen an aggregator that does > this Have a look at a decent newsreader. Agent, Xnews, Gnus and slrn for example. They all do this, and have done it for quite some years. They store the read Message-ID's across newsgroups so users shouldn't be bothered with reading already read articles over and over again. > More importantly, your scenario assumes that all 3 feeds are > republishing the atom:modified date from Norm's feed which in many > cases may not be true. Why not? And if they aren't republishing the date, that won't be catastrophic. The user agent would just have less metadata to base the decision of which entry is the most recent on. > What if PlanetXMLHack upgrades their server software which fixes some > transcription errors that have occured in how they emit feeds (I > believe Sam pointed some issues out in his blog) won't they change > atom:modified? No. Not at all. No intermediaries should change the value of atom:modified. Nor atom:content or atom:title, for that matter. > Using atom:modified in this scenario is a hack that will most > likely break down more often than it would work. I disagree. In your idea of atom:modified, there are no rules for who can modify its content and how it is transmitted. If you feel that the problem with the proposed text for atom:modified lies in the lack of these rules, then please say so. I think it's pretty obvious that an aggregator writer can't change the content of atom:content. I'd assume the same for atom:modified. -- 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 Sat Oct 30 09:37:50 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 JAA22858 for ; Sat, 30 Oct 2004 09:37:49 -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 i9UDScF6075733; Sat, 30 Oct 2004 06:28:38 -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 i9UDScee075732; Sat, 30 Oct 2004 06:28:38 -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 i9UDSbAh075666 for ; Sat, 30 Oct 2004 06:28:38 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 61759 messnum 15267658 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 30 Oct 2004 13:28:33 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail11.svc.cra.dublin.eircom.net (qp 61759) with SMTP; 30 Oct 2004 13:28:33 -0000 Message-ID: <418396FD.30400@dehora.net> Date: Sat, 30 Oct 2004 14:28:29 +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: PaceUpdatedDefinition References: <4182C9C0.1000600@franklinmint.fm> <1f2ed5cd0410300257371dafa1@mail.gmail.com> In-Reply-To: <1f2ed5cd0410300257371dafa1@mail.gmail.com> 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 Robert Sayre wrote: > The "atom:updated" element is a Date construct indicating the most > recent instant in time when a substantive modification to the > [feed/entry] was made. The value of atom:updated can be changed at > the producer's discretion. Eric Scheid wrote: > define 'substantive'. > > in the spirit of writing spec text, I suggest: > > For example, such changes might not include minor > adjustments like spelling and grammatical corrections. Danny Ayers wrote: > I realise that we don't really want to put behaviour definitions into > the spec, but it might help with the wording to imagine exactly what > behaviour we would expect in a typical client - say RSS Bandit. Folks, I've had a lot of helpful comments over the last day, but I still suspect I'm not getting something fundamental about these two dates. Why say "a substantive modification" or add discriminating text, when you can say "a change"? It's not really the client I'd be looking at re behaviour definitions. It's whether the producer wants to world's clients and intermediaries to know about the change. Suppose we had a UI screen for filling out entries: Your infammatory title: [ Lorem ipsum delor sucks! ] Your rabid entry: [ Lorem ipsum delor sit amem... ] [ ] [ ] [ ] [ ] Your misleading summary: [ This entry is about Java, not ] [ pig Latin... ] [Save changes] [Cancel] [x] (mark as updated) If you have 2 change states in the format, it seems to me you have to reflect the option to discriminate between them in the UI (unless we're talking about UIs that do NLP). But if you had that, you can have the back of the UI simply push atom:updated forward based on the users selection . I don't then see the need to discrimate change states in the format. cheers Bill From owner-atom-syntax@mail.imc.org Sat Oct 30 09:44: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 JAA23128 for ; Sat, 30 Oct 2004 09:44:05 -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 i9UDcDPB078115; Sat, 30 Oct 2004 06:38: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 i9UDcDiw078114; Sat, 30 Oct 2004 06:38:13 -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 i9UDcCx0078089 for ; Sat, 30 Oct 2004 06:38:13 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 707627C1EE; Sat, 30 Oct 2004 15:34:15 +0200 (CEST) Date: Sat, 30 Oct 2004 15:39:01 +0200 To: "Dare Obasanjo" Subject: Re: PaceDateModified Cc: Atom-Syntax References: <20041029012602.11845.qmail@web40810.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20041029012602.11845.qmail@web40810.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thu, 28 Oct 2004 18:26:02 -0700 (PDT), Dare Obasanjo wrote: > The PubSub folks have said they don't plan to consider entries with the > same ID in different feeds as the same due to spoofing. So because there _might_ be spoofers, we shold drop all features from the Atom protocol and format that _might_ be used for spoofing? Instead of killing the symptoms one by one in fear of what _might_ happen, can't we instead look for a solid solution for everything? Signatures, for example: . -- 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 Sat Oct 30 09:49:13 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 JAA23324 for ; Sat, 30 Oct 2004 09:49:13 -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 i9UDgLSA078928; Sat, 30 Oct 2004 06: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 i9UDgLSk078927; Sat, 30 Oct 2004 06:42:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9UDgKIx078905 for ; Sat, 30 Oct 2004 06:42:20 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 80790 messnum 5055205 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 30 Oct 2004 13:42:17 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail04.svc.cra.dublin.eircom.net (qp 80790) with SMTP; 30 Oct 2004 13:42:17 -0000 Message-ID: <41839A35.1090403@dehora.net> Date: Sat, 30 Oct 2004 14:42:13 +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: PaceDateModified References: <20041029124447.14794.qmail@web40802.mail.yahoo.com> 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: > I think it's pretty obvious that an aggregator writer can't change the > content of atom:content. I'd assume the same for atom:modified. Are you saying we're missing a few SHOULD NOTs? cheers Bill From owner-atom-syntax@mail.imc.org Sat Oct 30 10:14: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 KAA24926 for ; Sat, 30 Oct 2004 10:14:16 -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 i9UE4tCY083457; Sat, 30 Oct 2004 07:04: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 i9UE4t4u083456; Sat, 30 Oct 2004 07:04: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 (smtpgateway.itweb.no [213.236.233.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UE4seh083432 for ; Sat, 30 Oct 2004 07:04:54 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id A81AB7C1EE; Sat, 30 Oct 2004 16:00:57 +0200 (CEST) Date: Sat, 30 Oct 2004 16:05:47 +0200 To: "Tim Bray" , "Eric Scheid" Subject: Re: PaceDateModified Cc: "Atom Syntax" References: <145ADD3D-29D9-11D9-9F4E-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <145ADD3D-29D9-11D9-9F4E-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 29 Oct 2004 11:33:51 -0700, Tim Bray wrote: > Only if you trust atom:modified. But you've already decided not to > trust atom:updated, so why should you? This goes back four months to when we discussed atom:issued. Some thought it was an authorative (subjective) date, while others thought it was a machine-managed (objective) date. While most people agree on that atom:updated is authorative (or do we? I think the specification text for that date is incredibly ambiguous), I think there is not a common understanding of what atom:modified is. HTTP servers manages 'Last-Modified' automatically. I expect Atom tools to do the same. atom:updated is the authorative date in an entry, while atom:modified is the machine-generated, objective one. The first one tells you when the author wants you to re-read the entry, the last one tells the tool you're using when to update the entry in its database. The first one probably marks the entry as unread in your reader, the last one doesn't do anything visually in your reader at all. So, this is the subjective/objective discussion all over again, imho. We've had it before, and need to have it again, because it's a profound distinction we need to make in a publishing format and protocol. ...Which again brings me to the subject of separating protocol-metadata from format-metadata. In my opinion, atom:modified belongs to the protocol while atom:updated belongs along with the entry in the format. atom:updated is closer to the content, while atom:modified is closer to the protocol. No one else seems to think this distinction is useful, but I mention it again, nonetheless. -- 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 Sat Oct 30 10:22: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 KAA25629 for ; Sat, 30 Oct 2004 10:22:45 -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 i9UEHHSP086451; Sat, 30 Oct 2004 07:17:17 -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 i9UEHHYu086450; Sat, 30 Oct 2004 07:17:17 -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 i9UEHGJH086436 for ; Sat, 30 Oct 2004 07:17:16 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=franklinmint.fm) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNu2c-0004QH-10; Sat, 30 Oct 2004 14:17:14 +0000 Message-ID: <4183CC98.1000706@franklinmint.fm> Date: Sat, 30 Oct 2004 10:17:12 -0700 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceUpdatedDefinition References: <4182C9C0.1000600@franklinmint.fm> <1f2ed5cd0410300257371dafa1@mail.gmail.com> <418396FD.30400@dehora.net> In-Reply-To: <418396FD.30400@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > I've had a lot of helpful comments over the last day, but I still > suspect I'm not getting something fundamental about these two dates. > Why say "a substantive modification" or add discriminating text, when > you can say "a change"? > > It's not really the client I'd be looking at re behaviour definitions. > It's whether the producer wants to world's clients and intermediaries > to know about the change. Suppose we had a UI screen for filling out > entries: I've updated the Pace. The "atom:updated" element is a Date construct indicating the most recent instant in time when a modification to the [feed/entry] was made. The value of atom:updated can be changed at the producer's discretion, so not all modifications result in a changed atom:updated value. I will include no sentences about "typically" this or that, since the choice is entirely up to the producer. Besides, most software will probably change atom:updated wiith the most minor changes, as Roger says. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 30 10:31: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 KAA26056 for ; Sat, 30 Oct 2004 10:31:46 -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 i9UEP33S088077; Sat, 30 Oct 2004 07:25:03 -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 i9UEP3T3088076; Sat, 30 Oct 2004 07:25:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UEP2Gs088069 for ; Sat, 30 Oct 2004 07:25:02 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so116373rnb for ; Sat, 30 Oct 2004 07:25:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=QibNk6OWGxcAfn0uYawAbBtJR8EbD1WBlYeG73nCMOSU/qZB0WTCguCgmaXlTKRXsF/w9DD+O6b19Kn6EhXO1HLg8Ekeg00y7G1mjjQXOnPedSOTGRk7QX8bpHXYFAyOJy9IOUXe1k5xB8Er9NsWJwnN3OJIUiUeNIJn1YQLwpk= Received: by 10.38.98.30 with SMTP id v30mr745490rnb; Sat, 30 Oct 2004 07:25:02 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 07:25:02 -0700 (PDT) Message-ID: <1f2ed5cd04103007258fd7a5e@mail.gmail.com> Date: Sat, 30 Oct 2004 16:25:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceUpdatedDefinition Cc: Atom Syntax In-Reply-To: <418396FD.30400@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <4182C9C0.1000600@franklinmint.fm> <1f2ed5cd0410300257371dafa1@mail.gmail.com> <418396FD.30400@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9UEP3Gs088071 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 30 Oct 2004 14:28:29 +0100, Bill de hÓra wrote: > If you have 2 change states in the format, it seems to me you have > to reflect the option to discriminate between them in the UI (unless > we're talking about UIs that do NLP). But if you had that, you can > have the back of the UI simply push atom:updated forward based on > the users selection . I don't then see the need to discrimate change > states in the format. I don't entirely follow, but here's my reading of the situation. Assuming an entry had already been published, and later the author goes back to their UI and makes some minor changes. [Save changes] [x] (mark as updated) 1. Save changes is clicked, updated checked. The entry would now go out in the feed with atom:updated changed. When a client sees this entry it can do a comparison and replace its older version. The client UI may change the flag of the entry to 'unread' or make its title italic or whatever. [Save changes] [ ] (mark as updated) 2. Save changes is clicked, updated unchecked. The entry would now go out in the feed with all data exactly as when previously published, with the exception of whatever changes have been made to the content. If the client is subscribed *directly* to the originating feed, then it may pick up the changes and modify its local copy of the content. This presumably wouldn't be flagged to the user in any way they would notice in their general reading. This only works if two assumptions are made: that entries in more recently published feeds are more recent; that entry order with the feed is significant. The biggest problem as I see it is when the client isn't subscribed directly to the originating feed, a scenario that's becoming more common (Norm is already on at least two Planets plus PubSub and Feedster feeds). There have now been two versions of the entry published which differ only in their content. There is no longer any guarantee (if there ever was) that the entries will be received by the client in the order in which they were published. How is the client to know which version of the content is current? The only way around this is with what Bob described, that these entries are considered equivalent by the publisher so it simply doesn't matter - any version the client receives will do, whether or not it is the most recent. The heuristic that the most recently received is actually the most recent may help, but there are no guarantees. There hasn't been any acknowledgement from the anti-modified lobby that this would have to be accepted. Suggestions that the publisher may lie or that it's guesswork anyhow are orthogonal red herrings. We have to base the spec on the assumption that people will follow it, not on indeterminate bad practice. Resetting the atom:modified value whenever there has been a change to the entry makes explicit which is the more recent. The definition of "a change" isn't such a big deal: basically any difference in the document fragment corresponding to the entry as interpret by Atom - the spec could define this is terms of a simple diff on the element/attribute's content or something based on the infoset. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 11:02: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 LAA27536 for ; Sat, 30 Oct 2004 11:02: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 i9UEplCA093268; Sat, 30 Oct 2004 07:51:47 -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 i9UEpl31093267; Sat, 30 Oct 2004 07:51:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UEplnc093260 for ; Sat, 30 Oct 2004 07:51:47 -0700 (PDT) (envelope-from davemjohnson@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i9UEpnd8020532 for ; Sat, 30 Oct 2004 07:51:49 -0700 (PDT) Received: from [192.168.2.102] (adsl-221-27-58.rmo.bellsouth.net [68.221.27.58]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i9UEpmxD018017 for ; Sat, 30 Oct 2004 07:51:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1f2ed5cd0410300339e651901@mail.gmail.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-581708350 Message-Id: <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> From: Dave Johnson Subject: Re: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 10:53:12 -0400 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-581708350 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 30, 2004, at 6:39 AM, Danny Ayers wrote: > > Interop in the present environment means being able to bridge to RSS > systems. XSLT should offer a good approach. Yes, what better way to "how one migrates from the various RSS versions to the Atom syndication feed format" as the charter says. > > Having said all that, > > It's definitely something that needs to be looked at in more detail, > but I don't think this can be done right now - > > RSS 1.0 => Atom will be lossy, because of the lack of extension > support in Atom (e.g. try a Nature feed: http://www.nature.com/rss) Are extensions NOT part of the Atom charter? - Dave -- Dave Johnson http://rollerweblogger.org/page/roller --Apple-Mail-1-581708350 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Oct 30, 2004, at 6:39 AM, Danny Ayers wrote: Interop in the present environment means being able to bridge to RSS systems. XSLT should offer a good approach. Yes, what better way to "Verdanahow one migrates from the various RSS versions to the Atom syndication feed format" as the charter says. Having said all that, It's definitely something that needs to be looked at in more detail, but I don't think this can be done right now - RSS 1.0 => Atom will be lossy, because of the lack of extension support in Atom (e.g. try a Nature feed: http://www.nature.com/rss) Are extensions NOT part of the Atom charter? - Dave -- Dave Johnson http://rollerweblogger.org/page/roller --Apple-Mail-1-581708350-- From owner-atom-syntax@mail.imc.org Sat Oct 30 11:30:24 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 LAA29159 for ; Sat, 30 Oct 2004 11:30:23 -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 i9UFNP5o099957; Sat, 30 Oct 2004 08:23:25 -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 i9UFNP7x099956; Sat, 30 Oct 2004 08:23:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from lakermmtao05.cox.net (lakermmtao05.cox.net [68.230.240.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UFNOQ3099928 for ; Sat, 30 Oct 2004 08:23:24 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao05.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041030152320.IUNB16492.lakermmtao05.cox.net@A31P>; Sat, 30 Oct 2004 11:23:20 -0400 From: "Scott Hollenbeck" To: "'Dave Johnson'" , Subject: RE: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 11:23:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> Thread-Index: AcS+kIF5uMVKUFweSVKKgkoT3AgsEQAA61BQ Message-Id: <20041030152320.IUNB16492.lakermmtao05.cox.net@A31P> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Are extensions NOT part of the Atom charter? The answer is right in the charter [1] itself: "Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG." -Scott- atompub area advisor [1] http://www.ietf.org/html.charters/atompub-charter.html From owner-atom-syntax@mail.imc.org Sat Oct 30 11:30: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 LAA29174 for ; Sat, 30 Oct 2004 11:30:24 -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 i9UFHhWg098786; Sat, 30 Oct 2004 08:17:43 -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 i9UFHhbl098785; Sat, 30 Oct 2004 08:17:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UFHh1D098760 for ; Sat, 30 Oct 2004 08:17:43 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 86683 invoked by uid 17064); 30 Oct 2004 15:17:41 -0000 Received: from unknown (HELO [192.168.0.17]) ([83.112.232.173]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 30 Oct 2004 15:17:41 -0000 In-Reply-To: <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Dave Johnson From: Henry Story Subject: Re: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 17:17:36 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes, extensions are part of the Atom Charter, but the atom list seems to have come to a standstill on the issue. Any attempt to get the power of RDF enabled, which would be needed for RSS1.0 conversion, is heavily opposed by some. As a result there is no agreement on the issue yet, as far as I can tell. Henry On 30 Oct 2004, at 16:53, Dave Johnson wrote: > > On Oct 30, 2004, at 6:39 AM, Danny Ayers wrote: >> RSS 1.0 => Atom will be lossy, because of the lack of extension >> support in Atom (e.g. try a Nature feed: http://www.nature.com/rss) > > > Are extensions NOT part of the Atom charter? > > - Dave > > -- > Dave Johnson > http://rollerweblogger.org/page/roller From owner-atom-syntax@mail.imc.org Sat Oct 30 11:30:47 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 LAA29235 for ; Sat, 30 Oct 2004 11:30:46 -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 i9UFMWYA099795; Sat, 30 Oct 2004 08:22: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 i9UFMWZY099792; Sat, 30 Oct 2004 08:22:32 -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 i9UFMWNG099779 for ; Sat, 30 Oct 2004 08:22:32 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=franklinmint.fm) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNv3o-0006rb-7B; Sat, 30 Oct 2004 15:22:32 +0000 Message-ID: <4183DBE7.60005@franklinmint.fm> Date: Sat, 30 Oct 2004 11:22:31 -0700 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Johnson CC: atom-syntax@imc.org Subject: Re: A small suggestion for the Atom draft(s) References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> In-Reply-To: <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Johnson wrote: > Are extensions NOT part of the Atom charter? Of course they are. Call me crazy, but I think it *might* be possible to extend Atom with those wonderful Nature extensions. That said, we haven't nailed down our extension policy yet, so we'll continue to get inquiries like this until we do. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 30 11:45:24 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 LAA00390 for ; Sat, 30 Oct 2004 11:45:24 -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 i9UFavRa003028; Sat, 30 Oct 2004 08:36: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 i9UFav9M003027; Sat, 30 Oct 2004 08:36:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UFavaW003021 for ; Sat, 30 Oct 2004 08:36:57 -0700 (PDT) (envelope-from davemjohnson@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i9UFb0IP021167 for ; Sat, 30 Oct 2004 08:37:00 -0700 (PDT) Received: from [192.168.2.102] (adsl-221-27-58.rmo.bellsouth.net [68.221.27.58]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i9UFaveo026384 for ; Sat, 30 Oct 2004 08:36:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20041030152320.IUNB16492.lakermmtao05.cox.net@A31P> References: <20041030152320.IUNB16492.lakermmtao05.cox.net@A31P> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Johnson Subject: Re: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 11:38:22 -0400 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit oops, I was looking at the old charter http://www.intertwingly.net/wiki/pie/IetfCharter Thanks, - Dave On Oct 30, 2004, at 11:23 AM, Scott Hollenbeck wrote: > >> Are extensions NOT part of the Atom charter? > > The answer is right in the charter [1] itself: > > "Extension development is not included in this charter. The working > group will consider the need to either close or to modify the charter > and document extensions once the core document set has been approved > by the IESG." > > -Scott- > atompub area advisor > > [1] > http://www.ietf.org/html.charters/atompub-charter.html > From owner-atom-syntax@mail.imc.org Sat Oct 30 11:52:49 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 LAA01366 for ; Sat, 30 Oct 2004 11:52:48 -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 i9UFjxCf004760; Sat, 30 Oct 2004 08:45:59 -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 i9UFjxQ5004759; Sat, 30 Oct 2004 08:45:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UFjxNg004753 for ; Sat, 30 Oct 2004 08:45:59 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 15002 invoked by uid 17064); 30 Oct 2004 15:46:02 -0000 Received: from unknown (HELO [192.168.0.17]) ([83.112.232.173]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 30 Oct 2004 15:46:02 -0000 In-Reply-To: <20041030152320.IUNB16492.lakermmtao05.cox.net@A31P> References: <20041030152320.IUNB16492.lakermmtao05.cox.net@A31P> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Dave Johnson , Scott Hollenbeck From: Henry Story Subject: Re: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 17:45:56 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes but just above is says: "The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents." So how can you deliver an interoperable format if you don't allow or provide a mechanism to allow for extensions? Clearly the working group is not going to build the extensions themselves, which is what the text you quote is saying. But the text above says it has to provide for those to be developed. An RDF based format would automatically satisfy both. Henry Story On 30 Oct 2004, at 17:23, Scott Hollenbeck wrote: > >> Are extensions NOT part of the Atom charter? > > The answer is right in the charter [1] itself: > > "Extension development is not included in this charter. The working > group will consider the need to either close or to modify the charter > and document extensions once the core document set has been approved > by the IESG." > > -Scott- > atompub area advisor > > [1] > http://www.ietf.org/html.charters/atompub-charter.html > From owner-atom-syntax@mail.imc.org Sat Oct 30 12:03:22 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 MAA01861 for ; Sat, 30 Oct 2004 12:03: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 i9UFt4G1006481; Sat, 30 Oct 2004 08:55:04 -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 i9UFt4WL006480; Sat, 30 Oct 2004 08:55:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UFt2RE006474 for ; Sat, 30 Oct 2004 08:55:03 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9UFt5ui011522 for ; Sat, 30 Oct 2004 09:55:05 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6E00BKXMVTCH@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 30 Oct 2004 09:55:05 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6E00A6XMVSPH@mail.sun.net> for atom-syntax@imc.org; Sat, 30 Oct 2004 09:55:05 -0600 (MDT) Date: Sat, 30 Oct 2004 08:55:47 -0700 From: Tim Bray Subject: Re: PaceUpdatedDefinition In-reply-to: <4183CC98.1000706@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , =?ISO-8859-1?Q?Bill_de_h=D3ra?= Message-id: <2A39D924-2A8C-11D9-A367-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4182C9C0.1000600@franklinmint.fm> <1f2ed5cd0410300257371dafa1@mail.gmail.com> <418396FD.30400@dehora.net> <4183CC98.1000706@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 30, 2004, at 10:17 AM, Robert Sayre wrote: > I've updated the Pace. > > The "atom:updated" element is a Date construct indicating the most > recent instant in time when a modification to the [feed/entry] was > made. The value of atom:updated can be changed at the producer's > discretion, so > not all modifications result in a changed atom:updated value. s/modifications result/modifications necessarily result/. But actually, I'm OK with the text in the draft as it is. -Tim From owner-atom-syntax@mail.imc.org Sat Oct 30 12:10:44 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 MAA02116 for ; Sat, 30 Oct 2004 12:10: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 i9UG5bZh008423; Sat, 30 Oct 2004 09:05:37 -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 i9UG5brs008422; Sat, 30 Oct 2004 09:05:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from lakermmtao04.cox.net (lakermmtao04.cox.net [68.230.240.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UG5anK008398 for ; Sat, 30 Oct 2004 09:05:36 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao04.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041030160517.HLME23857.lakermmtao04.cox.net@A31P>; Sat, 30 Oct 2004 12:05:17 -0400 From: "Scott Hollenbeck" To: "'Henry Story'" , "'Atom Syntax'" Subject: RE: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 12:05:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcS+l5tqDzH827fnRqeLV+5OL/6ZagAAYblQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-Id: <20041030160517.HLME23857.lakermmtao04.cox.net@A31P> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > So how can you deliver an interoperable format if you don't > allow or provide a mechanism to allow for extensions? Extensibility is part of the charter. Extension development is not. It wasn't my intention to imply that the latter excluded the former. The question you asked, though, implies that extensibility is required for interoperability. I don't agree, but that's not the point of this thread and most likely because we have different thoughts about what "interoperable" means. -Scott- From owner-atom-syntax@mail.imc.org Sat Oct 30 12:14: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 MAA02267 for ; Sat, 30 Oct 2004 12:14:45 -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 i9UG70qG008732; Sat, 30 Oct 2004 09:07:00 -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 i9UG707U008731; Sat, 30 Oct 2004 09:07:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk ([161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UG6x0l008589 for ; Sat, 30 Oct 2004 09:06:59 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9UG0JK8013186; Sat, 30 Oct 2004 17:00:24 +0100 (BST) In-Reply-To: <4182C9C0.1000600@franklinmint.fm> References: <4182C9C0.1000600@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: PaceUpdatedDefinition Date: Sat, 30 Oct 2004 17:00:09 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29 Oct 2004, at 11:52 pm, Robert Sayre wrote: > None of the verbs or nouns in the phrase "bring to the attention of > subscribers" are defined in the spec, so we managed to reach consensus > on atom:updated without reaching consensus. This is a proposed > clarification/alteration/crusher-of-dreams. Choose your favorite > description. While I agree with the terminology problem, this new wording completely changes the meaning of the element (reading the original pace, it's pretty clear it was only meant for significant updates). Big fat -1. Graham From owner-atom-syntax@mail.imc.org Sat Oct 30 12:20:38 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 MAA02531 for ; Sat, 30 Oct 2004 12:20:37 -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 i9UGDOQd009972; Sat, 30 Oct 2004 09:13: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 i9UGDOb7009971; Sat, 30 Oct 2004 09:13:24 -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 i9UGDOOM009965 for ; Sat, 30 Oct 2004 09:13:24 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNvr2-0000NJ-BN; Sat, 30 Oct 2004 16:13:24 +0000 Message-ID: <4183BDA4.6050307@franklinmint.fm> Date: Sat, 30 Oct 2004 12:13:24 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax , =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceUpdatedDefinition References: <4182C9C0.1000600@franklinmint.fm> <1f2ed5cd0410300257371dafa1@mail.gmail.com> <418396FD.30400@dehora.net> <4183CC98.1000706@franklinmint.fm> <2A39D924-2A8C-11D9-A367-000A95A51C9E@sun.com> In-Reply-To: <2A39D924-2A8C-11D9-A367-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > s/modifications result/modifications necessarily result/. > Done. > But actually, I'm OK with the text in the draft as it is. -Tim > I'm OK with my interpretation of the text in the current draft, but not with the interpretation of others. A spelling correction may not big deal in long pieces like you write, but I tend to write about 10-20 words per post. A misspelled word can make something I write completely unparsable. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 30 12:22: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 MAA02598 for ; Sat, 30 Oct 2004 12:22:05 -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 i9UGD2BZ009882; Sat, 30 Oct 2004 09:13: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 i9UGD2xs009881; Sat, 30 Oct 2004 09:13:02 -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 i9UGD1Ix009875 for ; Sat, 30 Oct 2004 09:13:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNvqg-0000Mu-59; Sat, 30 Oct 2004 16:13:02 +0000 Message-ID: <4183BD8D.6060504@franklinmint.fm> Date: Sat, 30 Oct 2004 12:13:01 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom Syntax Subject: Re: PaceUpdatedDefinition References: <4182C9C0.1000600@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > While I agree with the terminology problem, this new wording completely > changes the meaning of the element (reading the original pace, it's > pretty clear it was only meant for significant updates). Big fat -1. Graham. Who decides what constitutes a significant update? Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 30 12:27:56 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 MAA02953 for ; Sat, 30 Oct 2004 12:27:55 -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 i9UGN0c4011854; Sat, 30 Oct 2004 09:23:00 -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 i9UGN0T8011852; Sat, 30 Oct 2004 09:23:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UGMxtY011803 for ; Sat, 30 Oct 2004 09:23:00 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9UGJ4AY017384; Sat, 30 Oct 2004 17:19:05 +0100 (BST) In-Reply-To: <4183BD8D.6060504@franklinmint.fm> References: <4182C9C0.1000600@franklinmint.fm> <4183BD8D.6060504@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65A6F58C-2A8F-11D9-8351-000A95DC3D90@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: PaceUpdatedDefinition Date: Sat, 30 Oct 2004 17:18:55 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30 Oct 2004, at 5:13 pm, Robert Sayre wrote: > Graham wrote: > >> While I agree with the terminology problem, this new wording >> completely changes the meaning of the element (reading the original >> pace, it's pretty clear it was only meant for significant updates). >> Big fat -1. > > Graham. Who decides what constitutes a significant update? For the millionth time, the publisher. Graham From owner-atom-syntax@mail.imc.org Sat Oct 30 12:27:58 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 MAA02982 for ; Sat, 30 Oct 2004 12:27:57 -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 i9UGMqSL011819; Sat, 30 Oct 2004 09:22: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 i9UGMqXd011818; Sat, 30 Oct 2004 09:22:52 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UGMoEc011804 for ; Sat, 30 Oct 2004 09:22:51 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd0410300339e651901@mail.gmail.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> Date: Sat, 30 Oct 2004 09:22:53 -0700 To: Atom WG From: Paul Hoffman / IMC Subject: Re: A small suggestion for the Atom draft(s) 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:39 PM +0200 10/30/04, Danny Ayers wrote: >I do think this is a good idea, and would hope to see something like >this at least as informative material associated with the spec. I'd >say it was closer to the core than Paul suggests, as the charter says: > >"The working group's primary focus will be on delivering an >interoperable format and corresponding protocol..." > >Interop in the present environment means being able to bridge to RSS >systems. Um, no it doesn't, and it never has. It's a bit late to start redefining basic terms in the charter. "Interoperable" means that anyone picking up our spec can make a product that interoperates with other product that follows the spec. At 10:53 AM -0400 10/30/04, Dave Johnson wrote: >On Oct 30, 2004, at 6:39 AM, Danny Ayers wrote: >> >>Interop in the present environment means being able to bridge to RSS >>systems. XSLT should offer a good approach. > >Yes, what better way to "how one migrates from the various RSS >versions to the Atom syndication feed format" as the charter says. Are we both looking at the same charter? I see nothing on that says that. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Oct 30 12:28:29 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 MAA03128 for ; Sat, 30 Oct 2004 12:28:28 -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 i9UGLK7M011514; Sat, 30 Oct 2004 09:21: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 i9UGLKxj011513; Sat, 30 Oct 2004 09:21:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UGLJ3U011507 for ; Sat, 30 Oct 2004 09:21:19 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so97356rnk for ; Sat, 30 Oct 2004 09:21:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kIsWcsfGwWb9fUINFdRi105dWE5LPkjekuT8AS0nClCfdljuYlPMEZxdpnInGNY1m34SkLEdHKuoiyuwD5k5ZZ2OdXJZkN9LsgIzPNnpDmbgWrR/XmzEsGWuGqdLExnz2TCE8JZ/wHthFx8ujoPcX51pkXCDOWo6Xtqbrzd32Vs= Received: by 10.38.8.65 with SMTP id 65mr748825rnh; Sat, 30 Oct 2004 09:21:15 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 09:21:14 -0700 (PDT) Message-ID: <1f2ed5cd041030092177f0e70a@mail.gmail.com> Date: Sat, 30 Oct 2004 18:21:14 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: PaceUpdatedDefinition Cc: Robert Sayre , Atom Syntax , =?ISO-8859-1?Q?Bill_de_h=D3ra?= In-Reply-To: <2A39D924-2A8C-11D9-A367-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4182C9C0.1000600@franklinmint.fm> <1f2ed5cd0410300257371dafa1@mail.gmail.com> <418396FD.30400@dehora.net> <4183CC98.1000706@franklinmint.fm> <2A39D924-2A8C-11D9-A367-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 08:55:47 -0700, Tim Bray wrote: > > On Oct 30, 2004, at 10:17 AM, Robert Sayre wrote: > > > I've updated the Pace. > > > > The "atom:updated" element is a Date construct indicating the most > > recent instant in time when a modification to the [feed/entry] was > > made. The value of atom:updated can be changed at the producer's > > discretion, so > > not all modifications result in a changed atom:updated value. > > s/modifications result/modifications necessarily result/. > > But actually, I'm OK with the text in the draft as it is. -Tim Might it be worth adding a note to clarify: "Where a client receives more than one version of an entry with the same atom:updated value, it will not be possible to determine which is the most recently modified version of that entry." Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 12:30: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 MAA03776 for ; Sat, 30 Oct 2004 12:30:50 -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 i9UGOAud012077; Sat, 30 Oct 2004 09:24:10 -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 i9UGOAZo012076; Sat, 30 Oct 2004 09:24:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UGOAt2012070 for ; Sat, 30 Oct 2004 09:24:10 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 44110 invoked by uid 17064); 30 Oct 2004 16:24:12 -0000 Received: from unknown (HELO [192.168.0.17]) ([83.112.232.173]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 30 Oct 2004 16:24:12 -0000 In-Reply-To: <20041030160517.HLME23857.lakermmtao04.cox.net@A31P> References: <20041030160517.HLME23857.lakermmtao04.cox.net@A31P> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1DC2788B-2A90-11D9-B5E8-000A95D9FA7A@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Scott Hollenbeck From: Henry Story Subject: Re: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 18:24:04 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30 Oct 2004, at 18:05, Scott Hollenbeck wrote: > >> So how can you deliver an interoperable format if you don't >> allow or provide a mechanism to allow for extensions? > > Extensibility is part of the charter. Extension development is not. > It > wasn't my intention to imply that the latter excluded the former. Ok. I agree with that position. > > The question you asked, though, implies that extensibility is required > for > interoperability. I don't agree, but that's not the point of this > thread > and most likely because we have different thoughts about what > "interoperable" means. Yes, I agree. I wrote my question a little too fast. The relation between extensibility and interoperability is not what supports the statement that extensibility is part of the charter. What supports it is the following text: "it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents." I now understand that you were responding literally to the form of Dave Johnson's question. I understood him to mean "Is extensibility not part of the charter?" It was the context of the question, as a response to Danny's pointing out that translating RSS1.0 into Atom would be lossy because of lack of "extension support" (= extensibilty) that makes me think that interpretation was the correct one. But it's not surprising to find oneself tripped up for these oversights in a syntax list :-) Henry > > -Scott- > From owner-atom-syntax@mail.imc.org Sat Oct 30 12:53: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 MAA04691 for ; Sat, 30 Oct 2004 12:53: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 i9UGjOOu016209; Sat, 30 Oct 2004 09:45: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 i9UGjO9o016208; Sat, 30 Oct 2004 09:45:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UGjNJs016180 for ; Sat, 30 Oct 2004 09:45:23 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id DA899B4 for ; Sat, 30 Oct 2004 09:45:19 -0700 (PDT) Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9UGjIhc025760 for ; Sat, 30 Oct 2004 09:45:19 -0700 (PDT) Date: Sat, 30 Oct 2004 09:45:20 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: A small suggestion for the Atom draft(s) Message-ID: In-Reply-To: <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Saturday, October 30, 2004 10:53 AM -0400 Dave Johnson wrote: >> On Oct 30, 2004, at 6:39 AM, Danny Ayers wrote: >> >> Interop in the present environment means being able to bridge to RSS >> systems. XSLT should offer a good approach. > > Yes, what better way to "how one migrates from the various RSS versions > to the Atom syndication feed format" as the charter says. I don't think that XSLT is a "better way" to document the mappings between the formats. A big table with comparable elements and notes would be a lot more informative than wading through multiple XSLT files. XSLT would be an excellent way to demonstrate interop, but not to describe how to migrate. And of course, running code is always a good thing for IETF specs, so the XSLT is quite welcome. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Oct 30 13:20:42 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 NAA06098 for ; Sat, 30 Oct 2004 13:20:41 -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 i9UHGDSc022373; Sat, 30 Oct 2004 10:16: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 i9UHGDA4022372; Sat, 30 Oct 2004 10:16:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UHGBEh022357 for ; Sat, 30 Oct 2004 10:16:11 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9UHGENH018247 for ; Sat, 30 Oct 2004 11:16:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6E00IPZQN2ND@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 30 Oct 2004 11:16:14 -0600 (MDT) Received: from [192.168.1.15] ([216.113.202.121]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I6E00ADSQMVPQ@mail.sun.net> for atom-syntax@imc.org; Sat, 30 Oct 2004 11:16:13 -0600 (MDT) Date: Sat, 30 Oct 2004 10:16:51 -0700 From: Tim Bray Subject: Re: PaceDateModified In-reply-to: <20041030171143.46826.qmail@web40809.mail.yahoo.com> To: Dare Obasanjo Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Atom Syntax , Eric Scheid Message-id: <7D3583D4-2A97-11D9-A367-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20041030171143.46826.qmail@web40809.mail.yahoo.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Oct 30, 2004, at 10:11 AM, Dare Obasanjo wrote: > RSS Bandit will always update the entry in regardless > of whatever the values of date fields are on the > entry. Entries change today in RSS & Atom feeds > without date fields changing and I don't expect this > behavior to change when Atom 1.0 is published. But Dare, with Atom, you really don't have to any more. It would be perfectly acceptable, when you read an Atom feed, to look at the atom:id and the atom:updated and just move along if you've seen the entry before with the same or a later date. There's nothing wrong with doing what you do, but I bet a lot of new implementors take the two-column-table approach that Bob suggested. -Tim From owner-atom-syntax@mail.imc.org Sat Oct 30 13:21:36 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 NAA06160 for ; Sat, 30 Oct 2004 13:21: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 i9UHF87N022166; Sat, 30 Oct 2004 10:15: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 i9UHF8PE022165; Sat, 30 Oct 2004 10:15:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40829.mail.yahoo.com (web40829.mail.yahoo.com [66.218.92.76]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9UHF7rs022139 for ; Sat, 30 Oct 2004 10:15:07 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041030171506.6142.qmail@web40829.mail.yahoo.com> Received: from [67.161.108.31] by web40829.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 10:15:06 PDT Date: Sat, 30 Oct 2004 10:15:06 -0700 (PDT) From: Dare Obasanjo Subject: Re: A small suggestion for the Atom draft(s) To: Henry Story , Atom Syntax Cc: Dave Johnson , Scott Hollenbeck In-Reply-To: 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: --- Henry Story wrote: > > So how can you deliver an interoperable format if > you don't allow or > provide a mechanism to allow for extensions? (a) No one has said that Atom won't have an extension mechanism. All I've heard people argue is that RDF-based extensibility will be the basis of it. (b) The ability to define extensions and interoperability are orthogonal. Does the fact that there is no extension mechanism for XML 1.0 mean it isn't interoperable? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 30 13:21:48 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 NAA06189 for ; Sat, 30 Oct 2004 13:21:48 -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 i9UHBjvT021237; Sat, 30 Oct 2004 10:11:45 -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 i9UHBjWq021236; Sat, 30 Oct 2004 10:11:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40809.mail.yahoo.com (web40809.mail.yahoo.com [66.218.78.186]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9UHBi0v021210 for ; Sat, 30 Oct 2004 10:11:44 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041030171143.46826.qmail@web40809.mail.yahoo.com> Received: from [67.161.108.31] by web40809.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 10:11:43 PDT Date: Sat, 30 Oct 2004 10:11:43 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: "Asbjørn" Ulsberg , Tim Bray , Eric Scheid Cc: Atom Syntax In-Reply-To: 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: --- Asbjørn Ulsberg wrote: > > atom:updated is the authorative date in an entry, > while atom:modified is > the machine-generated, objective one. The first one > tells you when the > author wants you to re-read the entry, the last one > tells the tool you're > using when to update the entry in its database. The > first one probably > marks the entry as unread in your reader, the last > one doesn't do anything > visually in your reader at all. RSS Bandit will always update the entry in regardless of whatever the values of date fields are on the entry. Entries change today in RSS & Atom feeds without date fields changing and I don't expect this behavior to change when Atom 1.0 is published. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 30 13:24:47 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 NAA06279 for ; Sat, 30 Oct 2004 13:24:46 -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 i9UHIjVh022864; Sat, 30 Oct 2004 10:18:45 -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 i9UHIi5P022859; Sat, 30 Oct 2004 10:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UHIiaE022843 for ; Sat, 30 Oct 2004 10:18:44 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so119754rnb for ; Sat, 30 Oct 2004 10:18:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gmpCeaTbJLOt+dX45Y8nD1qPExRVpPqRIPMltmb3D8PFZ/d5guiC/lKf7aYw3zaxf08YIKWck+5blFTr0dBZUq8xcBFrEjAkPHNhtwbsfXR1Ex/cnZudN2vIHJ4XE8VXSZghosDJQiQmgOL2xDSEORPm6wHsVtu6hkolTLFLVSM= Received: by 10.38.98.30 with SMTP id v30mr790717rnb; Sat, 30 Oct 2004 10:18:47 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 10:18:47 -0700 (PDT) Message-ID: <1f2ed5cd04103010186304c532@mail.gmail.com> Date: Sat, 30 Oct 2004 19:18:47 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: A small suggestion for the Atom draft(s) Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 09:22:53 -0700, Paul Hoffman / IMC wrote: > At 12:39 PM +0200 10/30/04, Danny Ayers wrote: > >I do think this is a good idea, and would hope to see something like > >this at least as informative material associated with the spec. I'd > >say it was closer to the core than Paul suggests, as the charter says: > > > >"The working group's primary focus will be on delivering an > >interoperable format and corresponding protocol..." > > > >Interop in the present environment means being able to bridge to RSS > >systems. > > Um, no it doesn't, and it never has. It's a bit late to start > redefining basic terms in the charter. > > "Interoperable" means that anyone picking up our spec can make a > product that interoperates with other product that follows the spec. Taking the narrowest possible interpretation is as much redefining basic terms as my pragmatic remark. But Atom doesn't exist in a void. There are other systems with which it will be desirable to interoperate. Most syndication systems currently use RSS. A large proportion of the people picking up our spec will be wanting to add Atom capability to existing RSS-capable systems. What will interop mean to them? I don't see any conflict between interop between systems based on the Atom format and protocol and interop between systems on the Web at large. You will be able to base shiny new VPNs on Atom, just as you will be able to extend existing systems to interoperate using Atom. For the latter, and in the interests of encouraging adoption of Atom, XSLT-based interfaces will probably be useful. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 13:26: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 NAA06306 for ; Sat, 30 Oct 2004 13:26: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 i9UHL86Q023343; Sat, 30 Oct 2004 10:21: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 i9UHL8wi023342; Sat, 30 Oct 2004 10:21:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40826.mail.yahoo.com (web40826.mail.yahoo.com [66.218.92.73]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9UHL8fe023317 for ; Sat, 30 Oct 2004 10:21:08 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041030172106.87721.qmail@web40826.mail.yahoo.com> Received: from [67.161.108.31] by web40826.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 10:21:06 PDT Date: Sat, 30 Oct 2004 10:21:06 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: Tim Bray Cc: "Asbjørn" Ulsberg , Atom Syntax , Eric Scheid In-Reply-To: <7D3583D4-2A97-11D9-A367-000A95A51C9E@sun.com> 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: --- Tim Bray wrote: > > But Dare, with Atom, you really don't have to any > more. It would be > perfectly acceptable, when you read an Atom feed, to > look at the > atom:id and the atom:updated and just move along if > you've seen the > entry before with the same or a later date. There's > nothing wrong with > doing what you do, but I bet a lot of new > implementors take the > two-column-table approach that Bob suggested. I doubt I'll take your advice. It costs nothing to replace the existing content with the content from the feed since I've already downloaded and parsed it. Especially since there is the off chance that the user fixed a typo or some inserted some new text but didn't update the date field. ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 30 13:29:48 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 NAA06420 for ; Sat, 30 Oct 2004 13:29:47 -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 i9UHOXsq024029; Sat, 30 Oct 2004 10:24: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 i9UHOXRl024028; Sat, 30 Oct 2004 10:24:33 -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 i9UHOWaw024022 for ; Sat, 30 Oct 2004 10:24:32 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CNwxs-0002tH-Nq; Sat, 30 Oct 2004 17:24:32 +0000 Message-ID: <4183CE50.30202@franklinmint.fm> Date: Sat, 30 Oct 2004 13:24:32 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom Syntax Subject: Re: PaceUpdatedDefinition References: <4182C9C0.1000600@franklinmint.fm> <4183BD8D.6060504@franklinmint.fm> <65A6F58C-2A8F-11D9-8351-000A95DC3D90@mac.com> In-Reply-To: <65A6F58C-2A8F-11D9-8351-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > >> >> Graham. Who decides what constitutes a significant update? > > > For the millionth time, the publisher. OK, I don't see how the current text differs in that respect, but I'll try to drive that point home, without mentioning "spelling" in a normative section of the spec. How's this: The "atom:updated" element is a Date construct indicating the most recent instant in time when the [feed/entry] was modified in a way the producer considers significant. Ergo, not all modifications necessarily result in a changed atom:updated value. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 30 13:41: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 NAA07023 for ; Sat, 30 Oct 2004 13:41: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 i9UHZoTg025827; Sat, 30 Oct 2004 10:35: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 i9UHZo8M025826; Sat, 30 Oct 2004 10:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UHZn10025811 for ; Sat, 30 Oct 2004 10:35:50 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so98525rnk for ; Sat, 30 Oct 2004 10:35:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Mx6NwdWm+PCjDSnt6+LjjUjZfNjXQFh7NmNL9dPPgzG9TyIvyXdyQ3UA0BZtyw5BVv6fMbZDmto9GDm+Kr7jTTImr4T0oexgrsrZnCzMrjlt6rkzNMM3LYG7ZDYEF3WVGTrSDa1TRF7vQxEcP8/sBEAlGx7qdIj1NTcxikAQiw0= Received: by 10.38.8.65 with SMTP id 65mr767991rnh; Sat, 30 Oct 2004 10:35:50 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 10:35:50 -0700 (PDT) Message-ID: <1f2ed5cd0410301035375e5ae1@mail.gmail.com> Date: Sat, 30 Oct 2004 19:35:50 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Walter Underwood Subject: Re: A small suggestion for the Atom draft(s) Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 09:45:20 -0700, Walter Underwood wrote: > I don't think that XSLT is a "better way" to document the mappings > between the formats. A big table with comparable elements and > notes would be a lot more informative than wading through multiple > XSLT files. > > XSLT would be an excellent way to demonstrate interop, but not to > describe how to migrate. But if the XSLT is accurate, it can do more than describe how to migrate, it can implement the migration. This isn't hypothetical - some of the input processing I had for an app [1] used XSLT to normalise the RSS 0.9x input to RSS 1.0. An Atom (0.3) => RSS 1.0 stylesheet became available from a third party [2]. A minor config change later I had Atom support. Cheers, Danny. [1] http://ideagraph.net/ [2] http://purl.org/net/syndication/subscribe/feed-rss1.0.xsl -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 13:42:59 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 NAA07096 for ; Sat, 30 Oct 2004 13:42:58 -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 i9UHbHAB026206; Sat, 30 Oct 2004 10:37:17 -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 i9UHbHIm026205; Sat, 30 Oct 2004 10:37:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UHbH9N026198 for ; Sat, 30 Oct 2004 10:37:17 -0700 (PDT) (envelope-from davemjohnson@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i9UHbKd8028027 for ; Sat, 30 Oct 2004 10:37:20 -0700 (PDT) Received: from [192.168.1.102] (rdu168-185-032.nc.rr.com [24.168.185.32]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i9UHbJ5W015860 for ; Sat, 30 Oct 2004 10:37:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <6C0A1E35-2A83-11D9-9A39-000D93297B94@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D0108EC-2A9A-11D9-9A39-000D93297B94@mac.com> Content-Transfer-Encoding: 7bit From: Dave Johnson Subject: Re: A small suggestion for the Atom draft(s) Date: Sat, 30 Oct 2004 13:38:46 -0400 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 30, 2004, at 12:45 PM, Walter Underwood wrote: > --On Saturday, October 30, 2004 10:53 AM -0400 Dave Johnson > wrote: >> Yes, what better way to "how one migrates from the various RSS >> versions >> to the Atom syndication feed format" as the charter says. > > I don't think that XSLT is a "better way" to document the mappings > between the formats. A big table with comparable elements and > notes would be a lot more informative than wading through multiple > XSLT files. Yes, you are correct and I take that back. XSLT is not necessarily the best way to document the mappings. However it does have the benefit of being "working code." - Dave > > XSLT would be an excellent way to demonstrate interop, but not to > describe how to migrate. > > And of course, running code is always a good thing for IETF specs, > so the XSLT is quite welcome. > > wunder > -- > Walter Underwood > Principal Architect, Verity > From owner-atom-syntax@mail.imc.org Sat Oct 30 13:45:58 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 NAA07191 for ; Sat, 30 Oct 2004 13:45:57 -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 i9UHf91L026927; Sat, 30 Oct 2004 10:41:09 -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 i9UHf8Tb026926; Sat, 30 Oct 2004 10:41:08 -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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UHf2d7026899; Sat, 30 Oct 2004 10:41:02 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd04103010186304c532@mail.gmail.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <1f2ed5cd04103010186304c532@mail.gmail.com> Date: Sat, 30 Oct 2004 10:41:05 -0700 To: Danny Ayers From: Paul Hoffman / IMC Subject: Re: A small suggestion for the Atom draft(s) Cc: Atom WG 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 7:18 PM +0200 10/30/04, Danny Ayers wrote: > > "Interoperable" means that anyone picking up our spec can make a >> product that interoperates with other product that follows the spec. > >Taking the narrowest possible interpretation is as much redefining >basic terms as my pragmatic remark. No, it's not. I am using the definition that is most common in the IETF, the forum for this standardization work. If you want to use a different definition, feel free to do so in a different forum. >But Atom doesn't exist in a void. >There are other systems with which it will be desirable to >interoperate. Most syndication systems currently use RSS. A large >proportion of the people picking up our spec will be wanting to add >Atom capability to existing RSS-capable systems. Of course. And you can help them do that with a non-WG document describing how to do so. I already proposed that yesterday. > What will interop >mean to them? I don't know, and neither do you. Are you suggesting that we spend WG time pondering this in case we want to change our charter? Such pondering, of course, comes at the expense of doing the real work we still have ahead of us. >I don't see any conflict between interop between systems based on the >Atom format and protocol and interop between systems on the Web at >large. You will be able to base shiny new VPNs on Atom, just as you >will be able to extend existing systems to interoperate using Atom. >For the latter, and in the interests of encouraging adoption of Atom, >XSLT-based interfaces will probably be useful. Maybe so; prove it. Write an individual Internet Draft. If folks agree with you, then it might become an RFC outside the Working Group. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Oct 30 13:57:44 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 NAA07705 for ; Sat, 30 Oct 2004 13:57:43 -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 i9UHqEUe029049; Sat, 30 Oct 2004 10:52:14 -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 i9UHqEMV029048; Sat, 30 Oct 2004 10:52:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UHqCvY029039 for ; Sat, 30 Oct 2004 10:52:12 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by rproxy.gmail.com with SMTP id 78so53401rnl for ; Sat, 30 Oct 2004 10:52:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FlyCietDNrOUxLqR0znhrkHOvQmfcq7OFb5whXS5Xjl1lS3Cv+L3RC37W6SyUgrs/ZKjPbAM3FMQu27E7vBF3iO1n3IVWR65fZ7DZj8FeUAThIjaC0M0dshOWeh7lGBMOcadrX7UYSThQ4yYE5ZQKtQE5APpRUKMAAkU0mIZc7c= Received: by 10.38.65.64 with SMTP id n64mr313945rna; Sat, 30 Oct 2004 10:52:15 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Sat, 30 Oct 2004 10:52:15 -0700 (PDT) Message-ID: <540e37320410301052415b5371@mail.gmail.com> Date: Sat, 30 Oct 2004 12:52:15 -0500 From: "Roger B." Reply-To: "Roger B." To: Robert Sayre Subject: Re: PaceUpdatedDefinition Cc: Atom Syntax In-Reply-To: <4183CE50.30202@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4182C9C0.1000600@franklinmint.fm> <4183BD8D.6060504@franklinmint.fm> <65A6F58C-2A8F-11D9-8351-000A95DC3D90@mac.com> <4183CE50.30202@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > The "atom:updated" element is a Date construct indicating the most > recent instant in time when the [feed/entry] was modified in a way > the producer considers significant. Ergo, not all modifications > necessarily result in a changed atom:updated value. +1... although I think I liked the last iteration a little better. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat Oct 30 14:05:36 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 OAA08227 for ; Sat, 30 Oct 2004 14:05: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 i9UHxS1D030828; Sat, 30 Oct 2004 10:59: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 i9UHxSH0030827; Sat, 30 Oct 2004 10:59:28 -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 i9UHxRMB030763 for ; Sat, 30 Oct 2004 10:59:27 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 1180F7C1EE; Sat, 30 Oct 2004 19:55:24 +0200 (CEST) Date: Sat, 30 Oct 2004 20:00:44 +0200 To: "Eric Scheid" Subject: Re: PaceDateModified Cc: Atom-Syntax , "Sam Ruby" References: From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 30 Oct 2004 10:05:18 +1000, Eric Scheid wrote: > perhaps then the spec should be updated such that atom:updated is specced > the way you want it - all changes get reflected in atom:updated. Indeed. It would be interesting to hear e.g. Sam Ruby's opinion (since he's the creator of atom:updated) on what an aggregator should do whenever atom:updated changes for a given entry. Should it: 1. Update the entry's content. 2. Mark the entry as unread. 3. Score it upwards in the message pool. 4. (And then) do nothing. The points above are not mutually exclusive, one might think that an aggregator can do 1 and 4, for example. I'd think it would be most useful if a change in atom:updated made the aggregator do 1 and 2, and if it had some kind of scoring system, then 3. If atom:updated is going to be used for both trivial and non-trivial changes, most users would probably like their aggregator to do 1 and 4 and not ever be bothered again, because else there would be too much noise. -- 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 Sat Oct 30 14:06:48 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 OAA08268 for ; Sat, 30 Oct 2004 14:06:48 -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 i9UI1iGf031405; Sat, 30 Oct 2004 11:01: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 i9UI1ipj031404; Sat, 30 Oct 2004 11:01:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UI1hCl031372 for ; Sat, 30 Oct 2004 11:01:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9UHhfSN006799; Sat, 30 Oct 2004 18:43:46 +0100 (BST) In-Reply-To: <4183CE50.30202@franklinmint.fm> References: <4182C9C0.1000600@franklinmint.fm> <4183BD8D.6060504@franklinmint.fm> <65A6F58C-2A8F-11D9-8351-000A95DC3D90@mac.com> <4183CE50.30202@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-591925437; protocol="application/pkcs7-signature" Message-Id: <35E5C4A0-2A9B-11D9-8351-000A95DC3D90@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceUpdatedDefinition Date: Sat, 30 Oct 2004 18:43:29 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-1-591925437 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 30 Oct 2004, at 6:24 pm, Robert Sayre wrote: > The "atom:updated" element is a Date construct indicating the most > recent instant in time when the [feed/entry] was modified in a way > the producer considers significant. Ergo, not all modifications > necessarily result in a changed atom:updated value. Yes, though I want to flip around the last sentence and say "Only a subset of modifications will result in etc". Graham --Apple-Mail-1-591925437 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDMwMTc0MzI5WjAjBgkqhkiG9w0BCQQxFgQURUq09zl3M3nvZL39sdAM+LKp mHcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA0314oHlivy+f4X9un1y6TPc6 hk1XzaLfkj/B+BKdWxIxbfb6UuLZu0IHV2Dp5rY3zjSYyMLyusyXJFEZYROj9Z8qQkxbfH9EHRzZ 3wUrhqOUbDoD3angTOPe1h2252wxtZBYKa/8H5ctOuUd1gSEs+0QRkjLk6iP/YWDBJGH/owK2LhL BeTThohbHW+XXLUUH4mZiEHLQt4StzFDAwMJLCzrtNYWs1wDr/DUNOPsLnMKWkjxTU+/tFNQs5Vr +9ugPD27TmiQaaQICpEUiRFyuZFRGNLGajwRtHYO2DCJW1okE1vQws1v3TLjEDuFH08ymCeIPwLG 8dfCoHyuzcl18AAAAAAAAA== --Apple-Mail-1-591925437-- From owner-atom-syntax@mail.imc.org Sat Oct 30 14:06:50 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 OAA08286 for ; Sat, 30 Oct 2004 14:06:50 -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 i9UI1jxQ031416; Sat, 30 Oct 2004 11:01:45 -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 i9UI1jwR031415; Sat, 30 Oct 2004 11:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UI1hCn031372 for ; Sat, 30 Oct 2004 11:01:45 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9UHlPks009629; Sat, 30 Oct 2004 18:47:25 +0100 (BST) In-Reply-To: References: <41823D5D.2050400@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-592150783; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sat, 30 Oct 2004 18:47:14 +0100 To: Tim Bray X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-592150783 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 29 Oct 2004, at 7:17 pm, Tim Bray wrote: > On Oct 29, 2004, at 5:53 AM, Graham Parks wrote: > >> Can I ask Tim, why do you hate XML namespaces? > > You could, and I'd answer "I don't, particularly". So perhaps you > should amplify the question. Because you've spend time creating a Pace that creates something very like XML namespaces, but isn't. Either you really hate the XML namespace system, or.. I have no idea. Put another way, why are we trying to shoehorn namespace functionality into the rel attribute, instead of seeing if we can add the functionality that we want to the pre-existing namespace system? If we accept PaceLinkByLocation and create an IANA thingy for new link types in the atom namespace, we'd have something functionally identical to PaceFieldingLinks (URI-based names, default short names, ability to extract all link constructs, etc), but be compatible with XMLNS. Graham --Apple-Mail-2-592150783 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDMwMTc0NzE1WjAjBgkqhkiG9w0BCQQxFgQUcbgvHx3CWKL3gqEzKhMC0oRt 0i0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAP9Qfb9XCkmqIi7lUgV1zMO+p TpwWUvxv6ZefMxKrVp2KuAuFmxQAHMxpkJwz5j+4KQ8mJipGBiUqkZrROe3U5eDBOuRNtvGSG7JJ 53OSOz9Bh1nwmxumXO7AC2T4XORWdinpGT8H9PD6hhbeaz5Fp2nkOPT1vpZVFFbOuM3iJJ//HAXw p4Bk33c3eKS4kvd+/W3LaCJloW0Ru4vUmhaOvyjt8tuS6fa3C4Zmuw4FKw8zFN/jpd0A2jQe4Owk JE3OozRkkvmc//oqvKEifP3ZtVZ0l52ZDsEKqnd26vc9uuedcvFGuxsmWQu67p+pfOBm6UNyMzjp vueHxaFcLIN8LAAAAAAAAA== --Apple-Mail-2-592150783-- From owner-atom-syntax@mail.imc.org Sat Oct 30 14:10: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 OAA08433 for ; Sat, 30 Oct 2004 14:10:45 -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 i9UI5PoY032347; Sat, 30 Oct 2004 11:05:25 -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 i9UI5PaP032346; Sat, 30 Oct 2004 11:05:25 -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 i9UI5OHk032315 for ; Sat, 30 Oct 2004 11:05:25 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id CB4647C1EE; Sat, 30 Oct 2004 20:01:27 +0200 (CEST) Date: Sat, 30 Oct 2004 20:06:48 +0200 To: "Tim Bray" Subject: Re: PaceDateModified Cc: Atom-Syntax References: <20041029190759.33454.qmail@web40828.mail.yahoo.com> <7D067C3B-29ED-11D9-9F4E-000A95A51C9E@sun.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <7D067C3B-29ED-11D9-9F4E-000A95A51C9E@sun.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 29 Oct 2004 13:59:56 -0700, Tim Bray wrote: > You don't feel it's worth suggesting that subscribers who read it should > re-read, but you'd like people who pick it up in future not to have to > read around the typo. I do this all the time on 'ongoing'. -Tim How do you know which version of your entry, which has the same atom:updated date and the same atom:id, is the most recent and correct one? This is not a good question if your entry is read in your feed only, but as Danny Ayers showed with his examples, one might pick up the same entry in several different feeds. So, the above question needs to be answered, imo. -- 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 Sat Oct 30 14:20: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 OAA08812 for ; Sat, 30 Oct 2004 14:20: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 i9UIDRcs034546; Sat, 30 Oct 2004 11:13:27 -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 i9UIDQQu034537; Sat, 30 Oct 2004 11:13:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UIDPWR034513 for ; Sat, 30 Oct 2004 11:13:26 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id v30so120986rnb for ; Sat, 30 Oct 2004 11:13:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=VNPSvjfHOAwE/4FsWS5oJnbMf5Nrl+XKW5+dCzXdc2+pwNLStCue+55+xOjgpvfI22Yh8hjCHQMM9uC8/Jg4VVy9tIk2QPszQQHPfUXEg50FFiPBvJQPAM7kPWGbA4LIILN5V4MivU5Foxo1Kgnd8u3uK0H0da3B0tlG7nHXhdo= Received: by 10.38.98.30 with SMTP id v30mr805694rnb; Sat, 30 Oct 2004 11:13:29 -0700 (PDT) Received: by 10.38.179.24 with HTTP; Sat, 30 Oct 2004 11:13:29 -0700 (PDT) Message-ID: <1f2ed5cd04103011133d5f6b10@mail.gmail.com> Date: Sat, 30 Oct 2004 20:13:29 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Paul Hoffman / IMC Subject: Re: A small suggestion for the Atom draft(s) Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <1f2ed5cd04103010186304c532@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 10:41:05 -0700, Paul Hoffman / IMC wrote: > At 7:18 PM +0200 10/30/04, Danny Ayers wrote: > > > "Interoperable" means that anyone picking up our spec can make a > >> product that interoperates with other product that follows the spec. > > > >Taking the narrowest possible interpretation is as much redefining > >basic terms as my pragmatic remark. > > No, it's not. I am using the definition that is most common in the > IETF, the forum for this standardization work. If you want to use a > different definition, feel free to do so in a different forum. If you can point me to the defining RFC, I will accept the definition. Otherwise I will continue to use what I consider to be an appropriate definition to facilitate the ends of this WG, in my role as a member of this WG. > >But Atom doesn't exist in a void. > >There are other systems with which it will be desirable to > >interoperate. Most syndication systems currently use RSS. A large > >proportion of the people picking up our spec will be wanting to add > >Atom capability to existing RSS-capable systems. > > Of course. And you can help them do that with a non-WG document > describing how to do so. I already proposed that yesterday. I'm sure a considerable amount of the material which will serve the end-users of this WG's chartered deliverables will appear outside of those deliverables. But it is worth bearing in mind that the more aspects of syndication are pushed to one side, the less relevance the WG will have to the end-users. That isn't necessarily a bad thing. > > What will interop > >mean to them? > > I don't know, and neither do you. Are you suggesting that we spend WG > time pondering this in case we want to change our charter? Such > pondering, of course, comes at the expense of doing the real work we > still have ahead of us. I'm not suggesting any changes to the charter. > >I don't see any conflict between interop between systems based on the > >Atom format and protocol and interop between systems on the Web at > >large. You will be able to base shiny new VPNs on Atom, just as you > >will be able to extend existing systems to interoperate using Atom. > >For the latter, and in the interests of encouraging adoption of Atom, > >XSLT-based interfaces will probably be useful. > > Maybe so; prove it. Write an individual Internet Draft. If folks > agree with you, then it might become an RFC outside the Working Group. Politics isn't really my medium. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Oct 30 16:00:27 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 QAA15677 for ; Sat, 30 Oct 2004 16:00:27 -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 i9UJmrTx054982; Sat, 30 Oct 2004 12:48: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 i9UJmrBs054981; Sat, 30 Oct 2004 12:48:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UJmqgM054966 for ; Sat, 30 Oct 2004 12:48:53 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id i9UJmr25007669; Sat, 30 Oct 2004 15:48:53 -0400 (EDT) Received: from BobT41 (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id BWT00917 (AUTH bob@wyman.us); Sat, 30 Oct 2004 15:48:53 -0400 (EDT) Message-Id: <200410301948.BWT00917@ms8.netsolmail.com> From: "Bob Wyman" To: "'Dare Obasanjo'" , "'Tim Bray'" Cc: "'AsbjXrn Ulsberg'" , "'Atom Syntax'" , "'Eric Scheid'" Subject: RE: PaceDateModified Date: Sat, 30 Oct 2004 15:48:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041030172106.87721.qmail@web40826.mail.yahoo.com> Thread-Index: AcS+phM/H22JhwoCR0qxf27VvkrHhQAD8gAQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dare Obasanjo wrote: >>--- Tim Bray wrote: >> I bet a lot of new implementors take the two-column-table approach >> that Bob suggested. > I doubt I'll take your advice. It costs nothing to >replace the existing content with the content from the >feed since I've already downloaded and parsed it. I wasn't really "suggesting" the two-column approach. Rather, I was just documenting what I thought were the logical implications of the statements that were being made by various "anti-modified" folk... I agree with Dare on this one. As long as you have a more recent copy of the entry, it makes sense that you would make it available to the user. At that point, the interesting question is whether or not you "bring it to the user's attention" by doing something like flagging it as unread. People's expectation for atom:updated seems to be that you would only re-set an entry to "unread" if atom:updated had been modified. It appears that there are at least four types of entries that may be handled by a news aggregator: 1. New entry. First entry instance which bears a specific atom:id 2. Updated entry. First enty instance which, while not a "New Entry", has a specific combination of atom:id + atom:updated value. 3. Modified entry. An entry which differs from an New or Updated Entry only in elements other than atom:id and atom:updated. 4. Duplicate entry. An entry which is identical, in all elements, to an entry previously received or processed. Is this list exhaustive? Am I missing something here? bob wyman From owner-atom-syntax@mail.imc.org Sat Oct 30 17: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 RAA19003 for ; Sat, 30 Oct 2004 17:20:32 -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 i9UL6QmJ071417; Sat, 30 Oct 2004 14:06:26 -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 i9UL6QX6071416; Sat, 30 Oct 2004 14:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UL6QWS071391 for ; Sat, 30 Oct 2004 14:06:26 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao07.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041030210619.VZGA17669.fed1rmmtao07.cox.net@[192.168.0.100]>; Sat, 30 Oct 2004 17:06:19 -0400 In-Reply-To: References: <41823D5D.2050400@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Tim Bray From: "Roy T. Fielding" Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sat, 30 Oct 2004 14:06:25 -0700 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 30, 2004, at 10:47 AM, Graham wrote: > On 29 Oct 2004, at 7:17 pm, Tim Bray wrote: > >> On Oct 29, 2004, at 5:53 AM, Graham Parks wrote: >> >>> Can I ask Tim, why do you hate XML namespaces? >> >> You could, and I'd answer "I don't, particularly". So perhaps you >> should amplify the question. > > Because you've spend time creating a Pace that creates something very > like XML namespaces, but isn't. Either you really hate the XML > namespace system, or.. I have no idea. The latter, most likely. > Put another way, why are we trying to shoehorn namespace functionality > into the rel attribute, instead of seeing if we can add the > functionality that we want to the pre-existing namespace system? Because rel corresponds better to the preferred behavior if the recipient does not understand the relationship name. That is, treat it as a generic link. > If we accept PaceLinkByLocation and create an IANA thingy for new link > types in the atom namespace, we'd have something functionally > identical to PaceFieldingLinks (URI-based names, default short names, > ability to extract all link constructs, etc), but be compatible with > XMLNS. That would be namespace-equivalent to requiring a centrally defined registry of relationship names, and a bunch of completely unknown elements in other namespace names. In order to tie the two together, Atom would have to use XLink attribute names to indicate that the other elements are actually links. Which choice is going to lead to better interoperability for folks who just want to blog their bits? XLink or rel? ....Roy From owner-atom-syntax@mail.imc.org Sat Oct 30 17:50:26 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 RAA20562 for ; Sat, 30 Oct 2004 17:50: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 i9ULaXrm078651; Sat, 30 Oct 2004 14:36: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 i9ULaX6q078650; Sat, 30 Oct 2004 14:36:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ULaWlL078625 for ; Sat, 30 Oct 2004 14:36:32 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9ULYOuH021729; Sat, 30 Oct 2004 22:34:29 +0100 (BST) In-Reply-To: <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> References: <41823D5D.2050400@mac.com> <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-605769765; protocol="application/pkcs7-signature" Message-Id: <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> Cc: Atom Syntax , Tim Bray From: Graham Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sat, 30 Oct 2004 22:34:13 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-605769765 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 30 Oct 2004, at 10:06 pm, Roy T. Fielding wrote: >> If we accept PaceLinkByLocation and create an IANA thingy for new >> link types in the atom namespace, we'd have something functionally >> identical to PaceFieldingLinks (URI-based names, default short names, >> ability to extract all link constructs, etc), but be compatible with >> XMLNS. > > That would be namespace-equivalent to requiring a centrally defined > registry of relationship names, and a bunch of completely unknown > elements in other namespace names. Which is exactly what Tim is proposing. > In order to tie the two together, > Atom would have to use XLink attribute names to indicate that the > other elements are actually links. > > Which choice is going to lead to better interoperability for folks > who just want to blog their bits? XLink or rel? If that's your only problem, may I point you to PaceLinkByLocation, which solves it*? Graham (* And which I mentioned at the very start of the proposal you're rebutting, but never mind) --Apple-Mail-2-605769765 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDMwMjEzNDE0WjAjBgkqhkiG9w0BCQQxFgQUQpTkTv0drc/6ssRzLvx/84WN aGkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAtOeDGYgMr6Fa5Tpxk2GZLCLH Tv5tflWQHgiti15Cya9CsV6844xTDJkyzE3gDq4fmBB0nYMof9fZGLeK/ySn8+OvhfHaoHEmGFgc MkGuIS+nJJlDmsnaLi0nF8wcri9sm4Qo003wSo/5rGQMsoqCsJ2cwra/yFTE3li0ApvvTUyqvnGK /6dpJ/l8NNCy5pcT/GLMnFINBi1MpUadW3rTm8ajQa/I5mpsG1Z+QaPYLFfT0CqooMxCalZHqSKC EnQBHGWYlBA+bfQYG8/7CzZi9UgFdlV7+TKyRAnFhOBqGr7p1JDO4ESFdpMEXuviOXWsriDrW4J6 kWlLXaH/K+2qKgAAAAAAAA== --Apple-Mail-2-605769765-- From owner-atom-syntax@mail.imc.org Sat Oct 30 18:14: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 SAA23049 for ; Sat, 30 Oct 2004 18:14:05 -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 i9UM6UBW084598; Sat, 30 Oct 2004 15:06:30 -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 i9UM6UCa084597; Sat, 30 Oct 2004 15:06:30 -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 i9UM6TqB084544 for ; Sat, 30 Oct 2004 15:06:29 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 91FE57C1EE; Sun, 31 Oct 2004 00:02:25 +0200 (CEST) Date: Sun, 31 Oct 2004 00:07:16 +0200 To: =?iso-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceDateModified Cc: Atom-Syntax References: <20041029124447.14794.qmail@web40802.mail.yahoo.com> <41839A35.1090403@dehora.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: <41839A35.1090403@dehora.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 30 Oct 2004 14:42:13 +0100, Bill de hÓra wrote: >> I think it's pretty obvious that an aggregator writer can't change the >> content of atom:content. I'd assume the same for atom:modified. > > Are you saying we're missing a few SHOULD NOTs? If we need to make it that explicit, then yes, maybe we are. -- 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 Sat Oct 30 18:17: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 SAA23455 for ; Sat, 30 Oct 2004 18:17: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 i9UMAIni085278; Sat, 30 Oct 2004 15:10: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 i9UMAIp2085277; Sat, 30 Oct 2004 15:10:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao11.cox.net (fed1rmmtao11.cox.net [68.230.241.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UMAI3e085261 for ; Sat, 30 Oct 2004 15:10:18 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao11.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041030221012.XUZT12244.fed1rmmtao11.cox.net@[192.168.0.100]>; Sat, 30 Oct 2004 18:10:12 -0400 In-Reply-To: <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> References: <41823D5D.2050400@mac.com> <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B7D1B63-2AC0-11D9-870A-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Tim Bray From: "Roy T. Fielding" Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sat, 30 Oct 2004 15:10:17 -0700 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > If that's your only problem, may I point you to PaceLinkByLocation, > which solves it*? I already did, and it doesn't solve it because namespaced elements define their own attribute grammars and there is no XML-significant way of saying "all child elements of this element have attributes named "href" that define links to the attribute value" other than XLink, which is why I mentioned it in the first place. ....Roy From owner-atom-syntax@mail.imc.org Sat Oct 30 18:25: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 SAA23836 for ; Sat, 30 Oct 2004 18:25:05 -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 i9UMEjZ1086191; Sat, 30 Oct 2004 15:14:45 -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 i9UMEj99086190; Sat, 30 Oct 2004 15:14:45 -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 i9UMEiQO086160 for ; Sat, 30 Oct 2004 15:14:45 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from quark (58.80-202-95.nextgentel.com [80.202.95.58]) by smtpgateway.itweb.no (Postfix) with ESMTP id 5F1FF7C1EE; Sun, 31 Oct 2004 00:10:47 +0200 (CEST) Date: Sun, 31 Oct 2004 00:15:39 +0200 To: "Dare Obasanjo" , "Tim Bray" , "Eric Scheid" Subject: Re: PaceDateModified Cc: "Atom Syntax" References: <20041030171143.46826.qmail@web40809.mail.yahoo.com> From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20041030171143.46826.qmail@web40809.mail.yahoo.com> User-Agent: Opera M2/7.54 (Win32, build 3865) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 30 Oct 2004 10:11:43 -0700 (PDT), Dare Obasanjo wrote: > RSS Bandit will always update the entry in regardless of whatever the > values of date fields are on the entry. Then RSS Bandit is vulnerable to spoofing already. How does atom:modified change that situation, specifically for RSS Bandit? I.e., how can the situation get any worse, when RSS Bandit already just eats everything it receives and overwrites everything it has? -- 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 Sat Oct 30 18:34:16 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 SAA24263 for ; Sat, 30 Oct 2004 18:34:15 -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 i9UMSnYn088211; Sat, 30 Oct 2004 15:28:49 -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 i9UMSnGX088210; Sat, 30 Oct 2004 15:28:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UMSm3I088134 for ; Sat, 30 Oct 2004 15:28:48 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 31 Oct 2004 09:28:27 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 31 Oct 2004 09:28:20 +1000 Subject: Re: PaceUpdatedDefinition From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4183CE50.30202@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 31/10/04 3:24 AM, "Robert Sayre" wrote: > The "atom:updated" element is a Date construct indicating the most > recent instant in time when the [feed/entry] was modified in a way > the producer considers significant. Ergo, not all modifications > necessarily result in a changed atom:updated value. +1 From owner-atom-syntax@mail.imc.org Sat Oct 30 18:34: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 SAA24266 for ; Sat, 30 Oct 2004 18:34:16 -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 i9UMRZM2088050; Sat, 30 Oct 2004 15:27:35 -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 i9UMRZRk088049; Sat, 30 Oct 2004 15:27:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UMRYnb088030 for ; Sat, 30 Oct 2004 15:27:35 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9UMFaRU028536; Sat, 30 Oct 2004 23:15:46 +0100 (BST) In-Reply-To: <7B7D1B63-2AC0-11D9-870A-000393753936@gbiv.com> References: <41823D5D.2050400@mac.com> <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> <7B7D1B63-2AC0-11D9-870A-000393753936@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-608239046; protocol="application/pkcs7-signature" Message-Id: <3190E280-2AC1-11D9-9BE3-000A95DC3D90@mac.com> Cc: Atom Syntax , Tim Bray From: Graham Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sat, 30 Oct 2004 23:15:22 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3-608239046 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 30 Oct 2004, at 11:10 pm, Roy T. Fielding wrote: > I already did, and it doesn't solve it because namespaced elements > define their own attribute grammars "All child elements of atom:links MUST be Link Constructs" > there is no XML-significant > way of saying "all child elements of this element have attributes > named "href" that define links to the attribute value" other than > XLink, > which is why I mentioned it in the first place. "All child elements of atom:links MUST be Link Constructs" Graham --Apple-Mail-3-608239046 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDMwMjIxNTIzWjAjBgkqhkiG9w0BCQQxFgQUq/UWJOl2sKFkSxB2rlN/oyyh O7MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEADOWRrIJNf2KceqfwWb4KtD9A NSjErXGukgrjHW1i9p7LPE01J0ymz4SuOVTp3tV5qZNJF9YxzXj8Kuth6Rfj6K/onqKj41UNDnvJ c515DZbwwu7mrrH0OMXD8Ivij686ZHiZF9uPbjLBdvHp4sp0J03/F25mMdgCUu03dvFoxOlyGfeM UzZ2BfA1jFpqBpINgq5UzvmhdddpYWoAqUhNJU7ISgtinenttvRiHckp9gwYWlBspkSS4cSmippw hv582+RZ1S96S1QcPk0W+IfSuUJomCkBlLU0dKHK0BCRg0g73ORK54cB61/WGfq4j6GWvLq9rJOb 3PrnHSEouxX/8gAAAAAAAA== --Apple-Mail-3-608239046-- From owner-atom-syntax@mail.imc.org Sat Oct 30 18:56:43 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 SAA26887 for ; Sat, 30 Oct 2004 18:56:42 -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 i9UMnSci090643; Sat, 30 Oct 2004 15:49: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 i9UMnSBb090642; Sat, 30 Oct 2004 15:49:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UMnRQo090630 for ; Sat, 30 Oct 2004 15:49:27 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 31 Oct 2004 09:49:36 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 31 Oct 2004 09:35:41 +1000 Subject: Re: PaceDateModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9UMnSQo090637 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 31/10/04 4:06 AM, "Asbjørn Ulsberg" wrote: >> You don't feel it's worth suggesting that subscribers who read it should >> re-read, but you'd like people who pick it up in future not to have to >> read around the typo. I do this all the time on 'ongoing'. -Tim > > How do you know which version of your entry, which has the same > atom:updated date and the same atom:id, is the most recent and correct one? > > This is not a good question if your entry is read in your feed only, but > as Danny Ayers showed with his examples, one might pick up the same entry > in several different feeds. So, the above question needs to be answered, > imo. also to consider is the odd effect of seeing a well written entry getting replaced with one with subtle spelling errors ... the reader may well assume you meant it that way and then send you email "correcting" you on your apparent bone-headed mis-spellings. I still get nit-picky email for stuff I wrote ages ago which I just wish I could fix and be done with. e. From owner-atom-syntax@mail.imc.org Sat Oct 30 19:13: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 TAA27799 for ; Sat, 30 Oct 2004 19:13:39 -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 i9UN5s7I093651; Sat, 30 Oct 2004 16:05:54 -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 i9UN5sSG093650; Sat, 30 Oct 2004 16:05:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UN5rZ7093634 for ; Sat, 30 Oct 2004 16:05:53 -0700 (PDT) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao06.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041030230541.ZENI24432.fed1rmmtao06.cox.net@[192.168.0.100]>; Sat, 30 Oct 2004 19:05:41 -0400 In-Reply-To: <3190E280-2AC1-11D9-9BE3-000A95DC3D90@mac.com> References: <41823D5D.2050400@mac.com> <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> <7B7D1B63-2AC0-11D9-870A-000393753936@gbiv.com> <3190E280-2AC1-11D9-9BE3-000A95DC3D90@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3F7C3FF9-2AC8-11D9-870A-000393753936@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Tim Bray From: "Roy T. Fielding" Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sat, 30 Oct 2004 16:05:53 -0700 To: Graham X-Mailer: Apple Mail (2.619) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Oct 30, 2004, at 3:15 PM, Graham wrote: > On 30 Oct 2004, at 11:10 pm, Roy T. Fielding wrote: > >> I already did, and it doesn't solve it because namespaced elements >> define their own attribute grammars > > "All child elements of atom:links MUST be Link Constructs" Which is a contradiction of XML namespaces. Either use them or invent your own, don't claim to be using them and using properties that they do not allow. ....Roy From owner-atom-syntax@mail.imc.org Sat Oct 30 19:32: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 TAA28646 for ; Sat, 30 Oct 2004 19:32:54 -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 i9UNMh5N096916; Sat, 30 Oct 2004 16:22:43 -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 i9UNMhVe096915; Sat, 30 Oct 2004 16:22:43 -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 i9UNMgl9096879; Sat, 30 Oct 2004 16:22:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with asmtp (Exim 4.34) id 1CO2YT-0008Hw-O9; Sat, 30 Oct 2004 23:22:41 +0000 Message-ID: <41842242.5050305@franklinmint.fm> Date: Sat, 30 Oct 2004 19:22:42 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: Atom WG Subject: PacePersonContructs (was: No consensus on PaceDateModified) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hey all, Let's stop talking about dates. I'm uncertain that atom:host is appropriate as a property of atom:person, but I accept the element has broadly applicable utility and is appropriate for inclusion in the core. Couldn't it also be a property of atom:entry? Seems like it's just in atom:person to satisfy a requirement of atom:person. Just to throw out a modification out there: x.x.x "atom:from" Element The "atom:from" element's content conveys information associated with the network origin of an Atom Entry. atom:entry elements MAY contain one atom:from element. Its content MUST be a domain name [RFC1035], a dotted-decimal IPv4 address, or a colon-delimited IPv6 address. Robert Sayre Paul Hoffman / IMC wrote: > > Wearing my co-chair hat, I am going to declare non-consensus on > PaceDateModified. (Friday afternoon is a good time to state the > obvious.) There are plenty of different people with different technical > objections to it. > > It's time for the WG to move on to the other items on the current work > rotation: > > At 1:30 PM -0400 10/28/04, Sam Ruby wrote: > >> Making link not required (in some circumstances): >> >> PaceContentOrLink >> PaceOptionalAlternateLink >> >> Error reporting: >> >> PaceErrVerb >> PaceServiceError >> >> Host from mod-wiki: >> >> PacePersonConstructs >> > From owner-atom-syntax@mail.imc.org Sat Oct 30 19:38:23 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 TAA29015 for ; Sat, 30 Oct 2004 19:38:22 -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 i9UNUFU6098385; Sat, 30 Oct 2004 16:30: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 i9UNUFKF098384; Sat, 30 Oct 2004 16:30:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UNUEBV098370 for ; Sat, 30 Oct 2004 16:30:15 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 31 Oct 2004 10:30:24 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 31 Oct 2004 10:30:17 +1000 Subject: Re: PacePersonConstructs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 9:21 AM, "Paul Hoffman / IMC" wrote: > It's time for the WG to move on to the other items on the current > work rotation: > > PacePersonConstructs > 3.2.4 "atom:host" Element > > The "atom:host" element's content conveys an IP address associated with the > Person construct. Person constructs MAY contain an atom:ipaddr element, but > MUST NOT contain more than one. Its content MUST be a domain name [RFC1035] or > a dotted-decimal IPv4 address or a colon-delimited IPv6 address. +1 simple enough, surely can't be controversial. also allows for machine generated content without requiring human-style identity attributes (email address, name) e. From owner-atom-syntax@mail.imc.org Sat Oct 30 19:41: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 TAA29246 for ; Sat, 30 Oct 2004 19:41: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 i9UNYCGI099150; Sat, 30 Oct 2004 16:34: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 i9UNYC9m099149; Sat, 30 Oct 2004 16:34:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UNYArn099134 for ; Sat, 30 Oct 2004 16:34:11 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 31 Oct 2004 10:34:20 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 31 Oct 2004 10:34:14 +1000 Subject: Re: PaceContentOrLink From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30/10/04 9:21 AM, "Paul Hoffman / IMC" wrote: > It's time for the WG to move on to the other items on the current > work rotation: > > PaceContentOrLink >> Replace the following paragraph in the 5.2 "atom:link" Element in the >> atom-format-02 draft: >> atom:entry elements MUST contain at least one atom:link element >> with a rel attribute value of "alternate". >> >> With the following: >> atom:entry elements that contain no child atom:content element >> MUST contain at least one atom:link element with a rel attribute >> value of "alternate". +1 I don't forsee any problems with this idea. The wording of the spec text might need to change if we change how atom:link elements work. e. From owner-atom-syntax@mail.imc.org Sat Oct 30 19:46: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 TAA29535 for ; Sat, 30 Oct 2004 19:46:29 -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 i9UNd0hl000227; Sat, 30 Oct 2004 16:39:00 -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 i9UNd0JF000226; Sat, 30 Oct 2004 16:39:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9UNcxkX000201 for ; Sat, 30 Oct 2004 16:39:00 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id i9UNaLW0014774; Sun, 31 Oct 2004 00:36:28 +0100 (BST) In-Reply-To: <3F7C3FF9-2AC8-11D9-870A-000393753936@gbiv.com> References: <41823D5D.2050400@mac.com> <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> <7B7D1B63-2AC0-11D9-870A-000393753936@gbiv.com> <3190E280-2AC1-11D9-9BE3-000A95DC3D90@mac.com> <3F7C3FF9-2AC8-11D9-870A-000393753936@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-613088030; protocol="application/pkcs7-signature" Message-Id: <7BC92C53-2ACC-11D9-9BE3-000A95DC3D90@mac.com> Cc: Atom Syntax , Tim Bray From: Graham Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance Date: Sun, 31 Oct 2004 00:36:11 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4-613088030 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 31 Oct 2004, at 12:05 am, Roy T. Fielding wrote: > On Oct 30, 2004, at 3:15 PM, Graham wrote: >> On 30 Oct 2004, at 11:10 pm, Roy T. Fielding wrote: >> >>> I already did, and it doesn't solve it because namespaced elements >>> define their own attribute grammars >> >> "All child elements of atom:links MUST be Link Constructs" > > Which is a contradiction of XML namespaces. Either use them or invent > your own, don't claim to be using them and using properties that they > do not allow. Are you seriously trying to argue that the Atom spec is not allowed to limit where and which namespaced elements are allowed to appear? I think you're very much mistaken. Graham --Apple-Mail-4-613088030 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDMwMjMzNjEyWjAjBgkqhkiG9w0BCQQxFgQU5BNQ0C5i8Wq+aJsJwpH5+jGr hg0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAyiZOtuKHM1uhIFPwS3ZRYAzu Or7SSvsvjG88RLAtSBXtEehrpa342zwJgqphtPo5zDdRQZPzzUkY1CYezCOXjSZxeNxMsioR3qH9 VrUQztiANEmJImwsn7km0kVMHlAeNrr0wQg8Optvzctf1O6mlyR9YRh5BB6nGU9mEVZGsiFmuqyA voopZ0Fgs5frCpjMl+OuWVyLwyqZGr46YrSu9o7vzFiCF6z05KpR5r4izqkeI07vuvTBPoxn9YhV LbxXbQNZTdjd7PGWDexV5LeMTAj4PTHVH1fylWAsT2EvUgO+A7aj/Q+lewkm/alBGmLG2v2kVbRA n4N+4XUOM9x+gAAAAAAAAA== --Apple-Mail-4-613088030-- From owner-atom-syntax@mail.imc.org Sat Oct 30 21:16:11 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 VAA03482 for ; Sat, 30 Oct 2004 21:16:10 -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 i9V17OSp016963; Sat, 30 Oct 2004 18:07: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 i9V17O3I016962; Sat, 30 Oct 2004 18:07:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V17NZa016947 for ; Sat, 30 Oct 2004 18:07:23 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by rproxy.gmail.com with SMTP id 78so78817rnl for ; Sat, 30 Oct 2004 18:07:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cLqEirHX5ZvLSnP9qK38fCaBssjSCDptfbneYk03nyz2deMAJdKAEMhPaOaS40jIUWRE+jeOXfS8dMwicNDmUanXPldGvmxPyRKkSXu6NwQWMu/PXLfq0v1hQNrnB1nV99qchJ1Mlk9QAPDgHCdO1KT9cuw+LQvD5wS1/Zccvgk= Received: by 10.38.99.17 with SMTP id w17mr474639rnb; Sat, 30 Oct 2004 18:07:29 -0700 (PDT) Received: by 10.38.96.31 with HTTP; Sat, 30 Oct 2004 18:07:29 -0700 (PDT) Message-ID: <540e373204103018072c7c2713@mail.gmail.com> Date: Sat, 30 Oct 2004 20:07:29 -0500 From: "Roger B." Reply-To: "Roger B." To: Robert Sayre Subject: Re: PacePersonContructs (was: No consensus on PaceDateModified) Cc: Atom WG In-Reply-To: <41842242.5050305@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41842242.5050305@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > x.x.x "atom:from" Element +1... I think that kind of thing is probably a better fit at the entry level. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat Oct 30 21:16: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 VAA03508 for ; Sat, 30 Oct 2004 21:16:15 -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 i9V12iMR016083; Sat, 30 Oct 2004 18:02: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 i9V12isR016082; Sat, 30 Oct 2004 18:02:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web40825.mail.yahoo.com (web40825.mail.yahoo.com [66.218.92.72]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9V12iGT016057 for ; Sat, 30 Oct 2004 18:02:44 -0700 (PDT) (envelope-from kpako@yahoo.com) Message-ID: <20041031010243.127.qmail@web40825.mail.yahoo.com> Received: from [24.18.132.123] by web40825.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 18:02:43 PDT Date: Sat, 30 Oct 2004 18:02:43 -0700 (PDT) From: Dare Obasanjo Subject: Re: PaceDateModified To: "Asbjørn" Ulsberg , Tim Bray , Eric Scheid Cc: Atom Syntax In-Reply-To: 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: --- Asbjørn Ulsberg wrote: > > > RSS Bandit will always update the entry in > regardless of whatever the > > values of date fields are on the entry. > > Then RSS Bandit is vulnerable to spoofing already. > How does atom:modified > change that situation, specifically for RSS Bandit? > I.e., how can the > situation get any worse, when RSS Bandit already > just eats everything it > receives and overwrites everything it has? I love it when people tell me how my own code works. RSS Bandit is vulnerable to spoofing if somehow someone manages to use DNS redirection or hack the web server to change the content of the feed. If that happens, then Yes RSS Bandit would have been "spoofed". However I'd be very impressed to see what techniques you propose aggregator implementations use to prevent such "spoofing". Basically I have no idea what your statement above has to do with the discussion at hand besides stating the blindingly obvious. Can you clarify? ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #222 I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Sat Oct 30 21:21: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 VAA03787 for ; Sat, 30 Oct 2004 21:21: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 i9V1F8L6018638; Sat, 30 Oct 2004 18:15: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 i9V1F88T018637; Sat, 30 Oct 2004 18:15:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V1F8Xx018619 for ; Sat, 30 Oct 2004 18:15:08 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 373BAB3 for ; Sat, 30 Oct 2004 18:15:09 -0700 (PDT) Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9V1F7hc026959 for ; Sat, 30 Oct 2004 18:15:08 -0700 (PDT) Date: Sat, 30 Oct 2004 18:15:10 -0700 From: Walter Underwood To: Atom WG Subject: Re: A small suggestion for the Atom draft(s) Message-ID: In-Reply-To: <1f2ed5cd04103011133d5f6b10@mail.gmail.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <1f2ed5cd04103010186304c532@mail.gmail.com> <1f2ed5cd04103011133d5f6b10@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Saturday, October 30, 2004 8:13 PM +0200 Danny Ayers wrote: > > If you can point me to the defining RFC, I will accept the definition. > Otherwise I will continue to use what I consider to be an appropriate > definition to facilitate the ends of this WG, in my role as a member > of this WG. Interoperability concerns implementations of the specification. MUST, SHOULD, and friends are defined in terms of that sort of interoperability. Any other definition is contrary to genera practice in IETF specifications. If you want to look for definitions, start with Tao of the IETF and also try RFC 2360, "Guide for Internet Standards Writers". wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Oct 30 21:37:55 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 VAA04611 for ; Sat, 30 Oct 2004 21:37:54 -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 i9V1TLFw020768; Sat, 30 Oct 2004 18:29: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 i9V1TL2o020767; Sat, 30 Oct 2004 18:29:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V1TKPt020757 for ; Sat, 30 Oct 2004 18:29:20 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 9DA8AB3 for ; Sat, 30 Oct 2004 18:29:21 -0700 (PDT) Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id i9V1TKhc026983 for ; Sat, 30 Oct 2004 18:29:21 -0700 (PDT) Date: Sat, 30 Oct 2004 18:29:23 -0700 From: Walter Underwood To: "'Atom Syntax'" Subject: RE: PaceDateModified Message-ID: <9491377F17EB4AEF380A77A3@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <200410301948.BWT00917@ms8.netsolmail.com> References: <200410301948.BWT00917@ms8.netsolmail.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Saturday, October 30, 2004 3:48 PM -0400 Bob Wyman wrote: > > People's expectation for atom:updated seems to be that you would only re-set > an entry to "unread" if atom:updated had been modified. Maybe not. My current preference would be for separate "read" and "changed" flags. I don't mind being notified that something has changed, but the "new on every change" behavior in NetNewWire is bugging me. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Oct 30 21:44: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 VAA04853 for ; Sat, 30 Oct 2004 21:44:20 -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 i9V1bPlK022221; Sat, 30 Oct 2004 18:37:25 -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 i9V1bP3e022220; Sat, 30 Oct 2004 18:37:25 -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 i9V1bPXo022214 for ; Sat, 30 Oct 2004 18:37:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=franklinmint.fm) by web02.designerslab.net with asmtp (Exim 4.34) id 1CO4ev-0004cY-9K; Sun, 31 Oct 2004 01:37:29 +0000 Message-ID: <41846C06.1030402@franklinmint.fm> Date: Sat, 30 Oct 2004 21:37:26 -0700 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: "Roy T. Fielding" , Atom Syntax , Tim Bray Subject: Re: Link housekeeping: PaceFieldingLinks and maintenance References: <41823D5D.2050400@mac.com> <8F034356-2AB7-11D9-870A-000393753936@gbiv.com> <71C28586-2ABB-11D9-9BE3-000A95DC3D90@mac.com> <7B7D1B63-2AC0-11D9-870A-000393753936@gbiv.com> <3190E280-2AC1-11D9-9BE3-000A95DC3D90@mac.com> <3F7C3FF9-2AC8-11D9-870A-000393753936@gbiv.com> <7BC92C53-2ACC-11D9-9BE3-000A95DC3D90@mac.com> In-Reply-To: <7BC92C53-2ACC-11D9-9BE3-000A95DC3D90@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: >> >> Which is a contradiction of XML namespaces. Either use them or invent >> your own, don't claim to be using them and using properties that they >> do not allow. > > > Are you seriously trying to argue that the Atom spec is not allowed to > limit where and which namespaced elements are allowed to appear? I think > you're very much mistaken. > I think Roy is pointing out that unprefixed attributes are undefined in XML Namespaces--"there is no way to construct universal names from unprefixed attribute names"[0]. In Infoset terms[1], all you have is an [owner element] and [local name], but no [namespace name], so it's not actually using xmlns. It's something different: {[namespace],[local name]} . [owns attr] . [local name] (no ns name) There is no concept of a "null namespace" or "no namespace" in xmlns, that's just shorthand that's not backed up by normative text. In this syntax, it's also invalid to write because "href" is in a namespace. In my original suggestion[2], the link attributes were in the Atom namespace. That syntax was actually using xmlns, but it was also a simplistic reinvention of XLink and/or HLink. The Namespace-based syntax also gives rise to the possibility of a profusion of xmlns declarations, which is just (my) bad syntax design. When you get right down to it, we're going to complicate the spec if we define links by containment instead of use a URI reference. Robert Sayre [0] http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4 [1] http://www.w3.org/TR/xml-infoset/#infoitem.attribute [2] http://www.imc.org/atom-syntax/mail-archive/msg10643.html From owner-atom-syntax@mail.imc.org Sat Oct 30 21:44: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 VAA04871 for ; Sat, 30 Oct 2004 21:44:24 -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 i9V1a73Z022000; Sat, 30 Oct 2004 18:36:07 -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 i9V1a7kw021999; Sat, 30 Oct 2004 18:36:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V1a6g1021897 for ; Sat, 30 Oct 2004 18:36:07 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 31 Oct 2004 12:35:46 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 31 Oct 2004 12:35:39 +1000 Subject: Re: PacePersonContructs (was: No consensus on PaceDateModified) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41842242.5050305@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 31/10/04 9:22 AM, "Robert Sayre" wrote: > x.x.x "atom:from" Element > > The "atom:from" element's content conveys information associated with > the network origin of an Atom Entry. atom:entry elements MAY contain one > atom:from element. Its content MUST be a domain name [RFC1035], a > dotted-decimal IPv4 address, or a colon-delimited IPv6 address. Sounds interesting ... but what role does that network origin play in the entry? That is, what role, other than or ? e. ps. +1 on expressing the idea as spec text. If only I was more considerate to do so more often. From owner-atom-syntax@mail.imc.org Sat Oct 30 21:53: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 VAA05538 for ; Sat, 30 Oct 2004 21:53: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 i9V1knNW023928; Sat, 30 Oct 2004 18:46:49 -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 i9V1kn0v023927; Sat, 30 Oct 2004 18:46:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V1kmxU023911 for ; Sat, 30 Oct 2004 18:46:48 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id 75so96109rnl for ; Sat, 30 Oct 2004 18:46:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kWmPq31wX9u7sXiQl/bWL7qASho7LojvrkWOx0Y26cKPiqx16VOOdIezrGc3IEFW47AwEQbMj4qy4yBdurvuTi1z0qY1BGp69hQB7Mb9AyN/4D7vylCuogXEUtATwwfd+zHkVARoxLN955AVmYEjYu57lfndzFevlVK+NyCaNYw= Received: by 10.38.24.46 with SMTP id 46mr557rnx; Sat, 30 Oct 2004 18:46:54 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Sat, 30 Oct 2004 18:45:24 -0700 (PDT) Message-ID: <3f1451f50410301845562d511e@mail.gmail.com> Date: Sat, 30 Oct 2004 21:45:24 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PacePersonContructs (was: No consensus on PaceDateModified) Cc: Paul Hoffman / IMC , Atom WG In-Reply-To: <41842242.5050305@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41842242.5050305@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 19:22:42 -0400, Robert Sayre wrote: > > Hey all, > > Let's stop talking about dates. > > I'm uncertain that atom:host is appropriate as a property of > atom:person, but I accept the element has broadly applicable utility and > is appropriate for inclusion in the core. Couldn't it also be a property > of atom:entry? Seems like it's just in atom:person to satisfy a > requirement of atom:person. I've read and re-read the above paragraph several times and can't make heads or tails of the point you are trying to make. Could you try again? > Just to throw out a modification out there: > > x.x.x "atom:from" Element > > The "atom:from" element's content conveys information associated with > the network origin of an Atom Entry. atom:entry elements MAY contain one > atom:from element. Its content MUST be a domain name [RFC1035], a > dotted-decimal IPv4 address, or a colon-delimited IPv6 address. I don't think atom:host is a great element name, but I don't particularly like atom:from either, too reminiscint of email. Why not atom:client-address? Either way, I am +1 on the element, it is definitely required by Wikis, usenet posts and anonymous comments. I am, however, opposed to the whole thing being named a 'Person' construct. I would prefer 'Author' or some other name that didn't imply a 1-1 correspondence with a human being. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sat Oct 30 22:07: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 WAA06005 for ; Sat, 30 Oct 2004 22:07:08 -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 i9V1wjaQ026398; Sat, 30 Oct 2004 18:58:45 -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 i9V1wjZk026397; Sat, 30 Oct 2004 18:58:45 -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 i9V1wip9026391 for ; Sat, 30 Oct 2004 18:58:45 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=franklinmint.fm) by web02.designerslab.net with asmtp (Exim 4.34) id 1CO4za-0005Ql-Bz; Sun, 31 Oct 2004 01:58:50 +0000 Message-ID: <41847107.5030709@franklinmint.fm> Date: Sat, 30 Oct 2004 21:58:47 -0700 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Atom WG Subject: Re: PacePersonContructs References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> In-Reply-To: <3f1451f50410301845562d511e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: >On Sat, 30 Oct 2004 19:22:42 -0400, Robert Sayre wrote: > > >>Hey all, >> >>Let's stop talking about dates. >> >>I'm uncertain that atom:host is appropriate as a property of >>atom:person, but I accept the element has broadly applicable utility and >>is appropriate for inclusion in the core. Couldn't it also be a property >>of atom:entry? Seems like it's just in atom:person to satisfy a >>requirement of atom:person. >> >> > >I've read and re-read the above paragraph several times and >can't make heads or tails of the point you are trying to make. >Could you try again? > > > I wrote "atom:person" but meant "a Person Construct". The Pace defines atom:host as component of a Person Construct, and I thought a child of atom:entry might be more appropriate, since the network origin of a post might have nothing to do with the "person", but is definitely the last known intermediary that transmitted the entry. >I don't think atom:host is a great element name, but I don't >particularly like atom:from either, too reminiscint of email. > > I chose "from" precisely because of that similarity :), but I don't particularly care what the element is called. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Oct 30 22:30:26 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 WAA06892 for ; Sat, 30 Oct 2004 22:30: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 i9V2G4xf028500; Sat, 30 Oct 2004 19:16:04 -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 i9V2G4hA028499; Sat, 30 Oct 2004 19:16:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V2G3UX028493 for ; Sat, 30 Oct 2004 19:16:04 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id 75so98111rnl for ; Sat, 30 Oct 2004 19:16:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hJek+UgjRqxt7Mri63ObUxA2lUKePgjjPf9X2GH+WGolDsg+V4v00Ep3URqvq2vzrjmdmwyNgi37+JfcY0ivu+dFHvQ9La3xrTwh7wbvZ+gzsCkAVq/+FudUCPXfUb5wznQFsgNAsC2bIusnXUnaYxDdRoiVMVpFoVRaiduh2mA= Received: by 10.38.13.26 with SMTP id 26mr17228rnm; Sat, 30 Oct 2004 19:16:02 -0700 (PDT) Received: by 10.38.151.28 with HTTP; Sat, 30 Oct 2004 19:16:00 -0700 (PDT) Message-ID: <3f1451f504103019167cc8ffd8@mail.gmail.com> Date: Sat, 30 Oct 2004 22:16:00 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: PacePersonContructs Cc: Atom WG In-Reply-To: <41847107.5030709@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> <41847107.5030709@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 21:58:47 -0700, Robert Sayre wrote: > I wrote "atom:person" but meant "a Person Construct". The Pace defines > atom:host as component of a Person Construct, and I thought a child of > atom:entry might be more appropriate, since the network origin of a post > might have nothing to do with the "person", but is definitely the last > known intermediary that transmitted the entry. Which is why I think we should change the name from Person Construct to Author Construct, i.e. we are recording information that, as much as is possible, indicates the author of the entry. I do see your point, that someone could have atom:name, atom:uri and atom:email in their entry, which identify the author quite well, and then on top of that atom:host could be added but if it only represents the last intermediary that transmitted the entry then it doesn't really add much. In fact it could detract from the other information given. I think we need some wording that indicates atom:host is a Person Construct Element Of Last Resort. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Oct 31 04:31:48 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 EAA10822 for ; Sun, 31 Oct 2004 04:31:48 -0500 (EST) 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 i9V9EeeP050720; Sun, 31 Oct 2004 01:14:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9V9EetM050719; Sun, 31 Oct 2004 01:14:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V9Eev3050688 for ; Sun, 31 Oct 2004 01:14:40 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so6496rnl for ; Sun, 31 Oct 2004 01:14:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nrHkS2f3tK/9Il0hoRkH/rTzeF3QusxdsfrQ2eKAMLGB5hCAkRuBUc52r3tRNoD0WcD1Ts6ifJhow20PybnSwWyiMeKTSOqea7FIL4GjenvG8YC3HZP9H+uMgBg/W+3t1apgMpAITXvMGvZYDL57CT/zMqupBgCVX72bABgQtpg= Received: by 10.38.12.80 with SMTP id 80mr70754rnl; Sun, 31 Oct 2004 01:14:40 -0800 (PST) Received: by 10.38.179.24 with HTTP; Sun, 31 Oct 2004 01:14:40 -0800 (PST) Message-ID: <1f2ed5cd04103101145f92412e@mail.gmail.com> Date: Sun, 31 Oct 2004 10:14:40 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Walter Underwood Subject: Re: A small suggestion for the Atom draft(s) Cc: atom-syntax@imc.org, phoffman@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <1f2ed5cd04103010186304c532@mail.gmail.com> <1f2ed5cd04103011133d5f6b10@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 30 Oct 2004 18:15:10 -0700, Walter Underwood wrote: > If you want to look for definitions, start with Tao of the IETF > and also try RFC 2360, "Guide for Internet Standards Writers". Thanks Walter. The second paragraph of the RFC makes the expected usage of the word clear, and I'll be glad to follow that definition in the context of IETF discussions. I apologise for any confusion I may have caused. It isn't the only definition available (check FOLDOC and Wikipedia), and I did actually quote the spec in my post - if there wasn't scope for interpretation, then any contradiction in my remarks would have been apparent, not requiring condemnation. Clearly there is scope for misinterpretation of such language for those of us not immersed in IETF arcana. But I'm sure the chairs will remain vigilant when it comes to clearing up such errors. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 31 04:37: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 EAA11126 for ; Sun, 31 Oct 2004 04:37:33 -0500 (EST) 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 i9V9UMFU058306; Sun, 31 Oct 2004 01:30:22 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9V9UMU8058302; Sun, 31 Oct 2004 01:30:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V9UL6P058287 for ; Sun, 31 Oct 2004 01:30:22 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so6678rnl for ; Sun, 31 Oct 2004 01:30:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=R9wEUlOhheOwOQQhsl02OGSVe6qYnO6WGvMcgOBwerkImGBsCmjbMruVJD0kZBzQ5z0fhQMgdxJ4He5wHzSrLBzUSKOSdefkWh07/EofnApwpqlmOrRPHFcDtRbQLE5GjUSnyyLmGnuRKvR4hb+tHITbk+/CGxZWaLiOecFv32Q= Received: by 10.38.12.80 with SMTP id 80mr73541rnl; Sun, 31 Oct 2004 01:30:22 -0800 (PST) Received: by 10.38.179.24 with HTTP; Sun, 31 Oct 2004 01:30:22 -0800 (PST) Message-ID: <1f2ed5cd041031013041d94609@mail.gmail.com> Date: Sun, 31 Oct 2004 10:30:22 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Joe Gregorio Subject: Re: PacePersonContructs (was: No consensus on PaceDateModified) Cc: Robert Sayre , Paul Hoffman / IMC , Atom WG In-Reply-To: <3f1451f50410301845562d511e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert: > > I'm uncertain that atom:host is appropriate as a property of > > atom:person, but I accept the element has broadly applicable utility and > > is appropriate for inclusion in the core. Couldn't it also be a property > > of atom:entry? Seems like it's just in atom:person to satisfy a > > requirement of atom:person. Joe: > I am, however, opposed to the whole thing being named a > 'Person' construct. I would prefer 'Author' or some other > name that didn't imply a 1-1 correspondence with a human > being. I think both comments are pointing in roughly the same direction - take the element out of the Person Construct and apply it directly to the entry (or feed). +1 to such a modification + to atom:from or atom:client-address in preference to atom:host, they're more explicit I think Joe's right about the correspondence with human beings, the mapping doesn't seem right, and might lead to incorrect assumptions in implementations. Separating the person from their role (e.g. 'author') is a possibility, one which has proved successful in FOAF. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 31 08:20: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 IAA25873 for ; Sun, 31 Oct 2004 08:20:00 -0500 (EST) 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 i9VD4WMK080930; Sun, 31 Oct 2004 05:04:32 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VD4WCH080929; Sun, 31 Oct 2004 05:04:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VD4VqF080907 for ; Sun, 31 Oct 2004 05:04:32 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id 75so134252rnl for ; Sun, 31 Oct 2004 05:04:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nScbyUHEYIzkuNhWXSJVySxmxFZtP0VtuY6Be983ZnQnuNnN7NnWnajp5PIC0BTC+sA8+jgl4scbLOXHZSyO8WqSG5IzmP5J7xuvCt5tlNmxIAmfYH13v+jzZeVUsyLX0JkAQn8s0boRfHBJrmHV2635dCAKYXTIJc3Y2deCNfQ= Received: by 10.38.72.21 with SMTP id u21mr158263rna; Sun, 31 Oct 2004 05:04:30 -0800 (PST) Received: by 10.38.151.28 with HTTP; Sun, 31 Oct 2004 05:04:30 -0800 (PST) Message-ID: <3f1451f504103105045c831862@mail.gmail.com> Date: Sun, 31 Oct 2004 08:04:30 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Danny Ayers Subject: Re: PacePersonContructs (was: No consensus on PaceDateModified) Cc: Robert Sayre , Paul Hoffman / IMC , Atom WG In-Reply-To: <1f2ed5cd041031013041d94609@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> <1f2ed5cd041031013041d94609@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 31 Oct 2004 10:30:22 +0100, Danny Ayers wrote: > Robert: > > > I'm uncertain that atom:host is appropriate as a property of > > > atom:person, but I accept the element has broadly applicable utility and > > > is appropriate for inclusion in the core. Couldn't it also be a property > > > of atom:entry? Seems like it's just in atom:person to satisfy a > > > requirement of atom:person. > > Joe: > > I am, however, opposed to the whole thing being named a > > 'Person' construct. I would prefer 'Author' or some other > > name that didn't imply a 1-1 correspondence with a human > > being. > > I think both comments are pointing in roughly the same direction - > take the element out of the Person Construct and apply it directly to > the entry (or feed). Personally, I wasn't trying to argue for that, I was arguing for just the opposite, that atom:host was just another piece of information identifying the author of the entry and so belonged in the 'Person Construct'. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Oct 31 12:07: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 MAA13441 for ; Sun, 31 Oct 2004 12:06:59 -0500 (EST) 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 i9VGoJre067454; Sun, 31 Oct 2004 08:50:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VGoJw2067453; Sun, 31 Oct 2004 08:50:19 -0800 (PST) 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-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VGoHnp067436 for ; Sun, 31 Oct 2004 08:50:18 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <1f2ed5cd04103101145f92412e@mail.gmail.com> References: <6.1.1.1.0.20041029223744.027d5af0@mail.comcast.net> <1f2ed5cd0410300339e651901@mail.gmail.com> <1f2ed5cd04103010186304c532@mail.gmail.com> <1f2ed5cd04103011133d5f6b10@mail.gmail.com> <1f2ed5cd04103101145f92412e@mail.gmail.com> Date: Sun, 31 Oct 2004 08:50:22 -0700 To: atom-syntax@imc.org From: Paul Hoffman / IMC Subject: Re: A small suggestion for the Atom draft(s) 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:14 AM +0100 10/31/04, Danny Ayers wrote: >But I'm sure the chairs will remain vigilant when it >comes to clearing up such errors. Will do. And this co-chair will also keep reminding people that it's *just fine* to write Internet Drafts that are not WG documents for things that are outside the scope of the WG. The WG charter is only supposed to constrain the discussion and products within the WG, not on the whole Internet. Some of the most useful RFCs are individual submissions that extend, help, or just explain WG-generated RFCs. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Oct 31 12:15:13 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 MAA13843 for ; Sun, 31 Oct 2004 12:15:13 -0500 (EST) 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 i9VH52E1073166; Sun, 31 Oct 2004 09:05:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VH52xB073165; Sun, 31 Oct 2004 09:05:02 -0800 (PST) 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 i9VH512g073129; Sun, 31 Oct 2004 09:05:01 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0ccekcs.cable.mindspring.com ([24.199.81.156] helo=franklinmint.fm) by web02.designerslab.net with asmtp (Exim 4.34) id 1COJ8V-0006od-PF; Sun, 31 Oct 2004 17:04:59 +0000 Message-ID: <4185456A.1060408@franklinmint.fm> Date: Sun, 31 Oct 2004 12:04:58 -0800 From: Robert Sayre User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio CC: Paul Hoffman / IMC , Atom WG Subject: Re: PacePersonContructs References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> <1f2ed5cd041031013041d94609@mail.gmail.com> <3f1451f504103105045c831862@mail.gmail.com> In-Reply-To: <3f1451f504103105045c831862@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: >Personally, I wasn't trying to argue for that, I was arguing >for just the opposite, that atom:host was just another >piece of information identifying the author of the entry and so belonged >in the 'Person Construct'. > > OK, we generally agree. * we both want the element * we both want to call it something different but I think it should be in atom:entry. The fact that wikis sometimes display that information in the author field doesn't mean it has anything to do with identity. I don't think I will change my position on this issue, but I'll go along with whatever the group decides. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Oct 31 14:31: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 OAA24031 for ; Sun, 31 Oct 2004 14:31:05 -0500 (EST) 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 i9VJFNDb019006; Sun, 31 Oct 2004 11:15:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VJFNEF019005; Sun, 31 Oct 2004 11:15:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VJF9dL018919 for ; Sun, 31 Oct 2004 11:15:17 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 80so18920rnl for ; Sun, 31 Oct 2004 11:15:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iZ6t3wlAkOEx11EOOO0SlkoxFIHRyYIl+BhBvUyhAz2LsjwbWHMvkKzdjwBNXcxW49kEWVECxoiUfQN9Fg4AonDedDWKm+Z616PmPmpCHLBJpFaIxqMQdx2fKAtjPLQ2RB8vxbWlxv6n2f05x2pBbvJJIsEPXCaKSrWRi4H+398= Received: by 10.38.12.80 with SMTP id 80mr203800rnl; Sun, 31 Oct 2004 11:15:04 -0800 (PST) Received: by 10.38.179.24 with HTTP; Sun, 31 Oct 2004 11:15:04 -0800 (PST) Message-ID: <1f2ed5cd04103111157e3e2ed1@mail.gmail.com> Date: Sun, 31 Oct 2004 20:15:04 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Robert Sayre Subject: Re: PacePersonContructs Cc: Joe Gregorio , Paul Hoffman / IMC , Atom WG In-Reply-To: <4185456A.1060408@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> <1f2ed5cd041031013041d94609@mail.gmail.com> <3f1451f504103105045c831862@mail.gmail.com> <4185456A.1060408@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 31 Oct 2004 12:04:58 -0800, Robert Sayre wrote: > > Joe Gregorio wrote: > > >Personally, I wasn't trying to argue for that, I was arguing > >for just the opposite, that atom:host was just another > >piece of information identifying the author of the entry and so belonged > >in the 'Person Construct'. Sorry I suggested otherwise. > OK, we generally agree. > > * we both want the element > * we both want to call it something different Ditto. > but > > I think it should be in atom:entry. The fact that wikis sometimes > display that information in the author field doesn't mean it has > anything to do with identity. I don't think I will change my position on > this issue, but I'll go along with whatever the group decides. I agree. This isn't information about the the author, the same author may be associated with different values of client address from one entry to the next. The primary use will no doubt be to tell if two entries have come from the same person, but that's a step the other side of a very loose heuristic. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sun Oct 31 18:01: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 SAA11915 for ; Sun, 31 Oct 2004 18:01:10 -0500 (EST) 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 i9VMjo1X090670; Sun, 31 Oct 2004 14:45:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VMjotT090668; Sun, 31 Oct 2004 14:45:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9VMjmit090612 for ; Sun, 31 Oct 2004 14:45:49 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 84852 messnum 6480978 invoked from network[83.70.253.75/83-70-253-75.b-ras1.prp.dublin.eircom.net]); 31 Oct 2004 22:45:45 -0000 Received: from 83-70-253-75.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.253.75) by mail12.svc.cra.dublin.eircom.net (qp 84852) with SMTP; 31 Oct 2004 22:45:45 -0000 Message-ID: <41856B15.2080604@dehora.net> Date: Sun, 31 Oct 2004 22:45:41 +0000 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 WG Subject: Re: PacePersonContructs References: <41842242.5050305@franklinmint.fm> <3f1451f50410301845562d511e@mail.gmail.com> <1f2ed5cd041031013041d94609@mail.gmail.com> <3f1451f504103105045c831862@mail.gmail.com> <4185456A.1060408@franklinmint.fm> In-Reply-To: <4185456A.1060408@franklinmint.fm> 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 Robert Sayre wrote: > I think it should be in atom:entry. This has been my position. > The fact that wikis sometimes > display that information in the author field doesn't mean it has > anything to do with identity. I don't think I will change my position on > this issue, but I'll go along with whatever the group decides. I would really like to see this item kicked out of the Author/Person construct. IP addresses identify computers, at best. Putting it in a Person construct is sloppy. cheers Bill From owner-atom-syntax@mail.imc.org Sun Oct 31 18:22:27 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 SAA14335 for ; Sun, 31 Oct 2004 18:22:27 -0500 (EST) 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 i9VNEIet000597; Sun, 31 Oct 2004 15:14:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VNEI7s000596; Sun, 31 Oct 2004 15:14:18 -0800 (PST) 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 i9VNEH4J000590 for ; Sun, 31 Oct 2004 15:14:17 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.9]) by web02.designerslab.net with asmtp (Exim 4.34) id 1COOtt-0005BC-LX; Sun, 31 Oct 2004 23:14:17 +0000 Message-ID: <418571C8.1080008@franklinmint.fm> Date: Sun, 31 Oct 2004 18:14:16 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom WG Subject: reject PaceErrVerb, and maybe PaceServiceError, too References: <41842242.5050305@franklinmint.fm> In-Reply-To: <41842242.5050305@franklinmint.fm> 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 Close PaceErrVerb. It's a nice idea that will never get done in this WG, if it's even possible at all. PaceServiceError could work. However, we have no specified notion of Errors or Conformance, so it's tough to tell whether the proposal would be helpful. If we come up with a status quo position on conformance, then I would definitely want it in 1.0. A Dead Letter Office is better than nothing. If we decide on something better, then it could be something added later if required. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Oct 31 18:51:23 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 SAA16077 for ; Sun, 31 Oct 2004 18:51:23 -0500 (EST) 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 i9VNcp2G007853; Sun, 31 Oct 2004 15:38:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9VNcpk2007852; Sun, 31 Oct 2004 15:38:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9VNcnc2007761 for ; Sun, 31 Oct 2004 15:38:50 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 1 Nov 2004 10:38:28 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 01 Nov 2004 10:38:23 +1100 Subject: Re: PacePersonContructs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41856B15.2080604@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9VNcoc2007846 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 1/11/04 9:45 AM, "Bill de hÓra" wrote: > I would really like to see this item kicked out of the Author/Person > construct. IP addresses identify computers, at best. Putting it in a > Person construct is sloppy. for the wiki case, the author/contributor is very likely human ... but we shouldn't assume that for all authors/contributors are human. It's quite possible that it could be an actual machine. e. From owner-atom-syntax@mail.imc.org Sun Oct 31 20:06: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 UAA20855 for ; Sun, 31 Oct 2004 20:05:59 -0500 (EST) 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 iA10rapg024407; Sun, 31 Oct 2004 16:53:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA10raag024405; Sun, 31 Oct 2004 16:53:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA10rZC8024351 for ; Sun, 31 Oct 2004 16:53:35 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 74325AA; Sun, 31 Oct 2004 16:53:34 -0800 (PST) Received: from adsl-64-166-133-243.dsl.snfc21.pacbell.net (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id iA10rWKB004088; Sun, 31 Oct 2004 16:53:33 -0800 (PST) Date: Sun, 31 Oct 2004 16:53:37 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: PacePersonContructs Message-ID: <24770571890F76DDA40AA076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Monday, November 1, 2004 10:38 AM +1100 Eric Scheid wrote: > > for the wiki case, the author/contributor is very likely human ... but we > shouldn't assume that for all authors/contributors are human. It's quite > possible that it could be an actual machine. Press releases have organizations for authors, not persons. Data feeds (a streamflow meter) have machines as authors. If we want a model for authors, I recommend starting with library practice and trying to build a schema from that. Note that libraries don't try to model the relationships between authors, noms de plume, and actual people. Instead, they have an authoritative list for author names. That is, we always spell "Shakespeare" the same way, the way it is in this list. To understand current library practice, I'd probably start with the Library of Congress pages on MARC (MAchine Readable Cataloging). The MARC format has a real COBOL/magtape feel to it, but it is a solid, functional standard. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun Oct 31 20:14: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 UAA21143 for ; Sun, 31 Oct 2004 20:14:33 -0500 (EST) 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 iA115dBr028320; Sun, 31 Oct 2004 17:05:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA115dcq028319; Sun, 31 Oct 2004 17:05:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA115c8L028303 for ; Sun, 31 Oct 2004 17:05:39 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 92FAC4F136; Sun, 31 Oct 2004 20:05:42 -0500 (EST) Message-Id: <6.0.0.20.2.20041101092215.07d081f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 01 Nov 2004 09:27:11 +0900 To: Eric Scheid , Atom Syntax From: Martin Duerst Subject: Re: PacePersonConstructs In-Reply-To: References: Mime-Version: 1.0 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 >On 30/10/04 9:21 AM, "Paul Hoffman / IMC" wrote: > >> It's time for the WG to move on to the other items on the current >> work rotation: >> >> PacePersonConstructs > >> 3.2.4 "atom:host" Element >> >> The "atom:host" element's content conveys an IP address associated with the >> Person construct. Person constructs MAY contain an atom:ipaddr element, but >> MUST NOT contain more than one. Its content MUST be a domain name [RFC1035] or >> a dotted-decimal IPv4 address or a colon-delimited IPv6 address. - It's weird to have the IP address either in the atom:ipaddr element or in the atom:host element. I think it's better to use host for domain names (including IDNs!), and ipaddr for IP addresses. - For IP addresses, we should consider whether we might want to also allow the IPvFuture syntax from http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt, just to be on the safe side. Regards, Martin. From owner-atom-syntax@mail.imc.org Sun Oct 31 21:15: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 VAA25079 for ; Sun, 31 Oct 2004 21:15:25 -0500 (EST) 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 iA122DuM046490; Sun, 31 Oct 2004 18:02:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA122DK1046487; Sun, 31 Oct 2004 18:02:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailgw.afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA122Ben046413 for ; Sun, 31 Oct 2004 18:02:12 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.2] (HELO afc.gov.au) by mailgw.afc.gov.au (CommuniGate Pro SMTP 4.2.5) with ESMTP id 1529161 for atom-syntax@imc.org; Mon, 01 Nov 2004 13:02:06 +1100 Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.5) with ESMTP id 1672703 for atom-syntax@imc.org; Mon, 01 Nov 2004 13:02:04 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 01 Nov 2004 13:01:39 +1100 Subject: Re: PacePersonContructs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <24770571890F76DDA40AA076@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1/11/04 11:53 AM, "Walter Underwood" wrote: > Press releases have organizations for authors, not persons. Depends on what you mean by "persons". Corporations are persons, as per a legal definition, but that's a bit out there. Meanwhile, I'm sure there are a few blogs out there where the putative author "person" is not a human: dogs, cats, Mr Sun, etc. As it is, while the spec refers to a "person construct", you won't find a in any atom feed ... they are all or ... and that's the intent there (if I may be so brazen ;-) I think "person construct" is so much simpler than "source of content entity" e. 
Greg,

  
(Note also that WWW-Authenticate is protocol dependent, which -- so 
far --  much of Atom is not.)
      
The Atom publishing protocol *is* HTTP specific. Completely. 
I haven't heard of any desire nor attempt to deal with 
protocols other than HTTP. So I'd suggest that being 
"specific" is not a problem.
    

OK .... I'd like to see Atom less protocol-dependent. ;)

Many of the services around at the moment already offer the ability to blog
via email, for example. How is that specified in Atom? From what you've
said, it just isn't. Anyone that offers such a feature simply 'steps
outside' of the Atom protocol. That doesn't bode well for the future, as
people add blogging via mobile phone, email, SMS messages, or whatever.
Surely we need to be able to express end-points dynamically?

As of today, our XForms processor can already 'submit' XML documents in many
different ways from the same form, including via SMTP. So, we could easily
extend our formsPlayer blogging client demo to send updates via email by a
simple change in the submission element -- no additional code. Except we
can't, because we currently could not get the end-point information at
run-time, and so would need to hard-code the email address.

I realise it's not completely trivial to add such a feature, but I suggest
it's worth considering how dependent Atom should be on HTTP if Atom is to
fulfil its promise.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/