From owner-atom-syntax@mail.imc.org Tue Jan 01 09:26:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9i4H-0002OB-K4 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:26:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9i4F-00036F-V6 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:26:09 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01E9k33060663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 07:09:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01E9kta060662; Tue, 1 Jan 2008 07:09:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01E9jYp060656 for ; Tue, 1 Jan 2008 07:09:45 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 9A821DD60E; Tue, 1 Jan 2008 14:09:43 +0000 (UTC) Message-ID: <477A49A8.4020904@dehora.net> Date: Tue, 01 Jan 2008 14:09:44 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James M Snell CC: Steven Lees , James Holderness , "'Atom-Syntax'" Subject: Re: Tombstones References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <004f01c841d8$26a33270$0701a8c0@Junk> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <20071219150157.GU15399@klangraum> <9F59E90E6E525B40BB7B59BD72271CF763FF60945A@NA-EXMSG-C103.redmond.corp.microsoft.com> <47694FB7.7040100@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FF60973B@NA-EXMSG-C103.redmond.corp.microsoft.com> <47699F24.9060701@gmail.com> In-Reply-To: <47699F24.9060701@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.8 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 James M Snell wrote: > Soft-delete is a special case. Soft delete is a move operation, it's not that special. What's special is the need to be able to move it back, like an OS trashcan. So when I see things like rel="trash", I suspect there's a use-case specific modelling problem stopping a general purpose solution getting out. > With this, entries are moved to a trash > collection. We need a way of indicating that the entry has been removed > from it's original feed, while at the same time indicating it's new > location in the trash feed, e.g., something along the lines of: > > > tag:example.org,2007:foo > type="application/atom+xml" > href="/trash/foo" /> > > > Entries in the trash collection can be undeleted or purged. If they are > undeleted, they go back to the original feed and are removed from the > trash. If they are purged, all of the metadata, save the id and perhaps > a timestamp, will be removed from the database. I can see why you need a way to indicate where the trashed entry should go back to, but not where it went to /from/ the original feed. If you really need that, I suggest you need to generalise it to a moved-from marker. In that case, don't bake the notion of "trash" or "delete" into a design for soft delete - it's a move op. I have other concerns, - about this kind of metadata becoming accumulated cruft, that requires extra tooling to clean up. - mixing up the state and housing of an entry with its type (a tombstone is a thing, but the person underneath it is surely dead). >> 7) one way (master-replica) full and incremental sync. > > This is a significant use case for us. We must have a reliable and > performant one-way sync model that can support full and incremental > operation. By incremental I mean we need to have the ability to request > a feed listing only changes that have occurred since the previous sync > operation. We've been here before. You can't do this without a timestamp (or some temporal ordering) that everyone agrees on (where 'everyone' is all the clients using the server). cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 09:46:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9iNk-00055z-Nt for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:46:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9iNk-0003Gq-BG for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:46:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01EXmME061531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 07:33:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01EXmcs061530; Tue, 1 Jan 2008 07:33:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01EXl89061524 for ; Tue, 1 Jan 2008 07:33:47 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id D732FDD763; Tue, 1 Jan 2008 14:33:45 +0000 (UTC) Message-ID: <477A4F49.5070900@dehora.net> Date: Tue, 01 Jan 2008 14:33:45 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James M Snell CC: Joe Gregorio , David Powell , Steven Lees , Mark Nottingham , Atom Syntax Subject: Re: Tombstones References: <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> In-Reply-To: <4768122A.3050801@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d James M Snell wrote: > That said, what is the value of reusing atom:entry in this case? > > Why is this... > > > tag:example.org,2007:/the/only/useful/thing/here > 2007-12-12T12:12:12Z > useless > useless > useless > > > Better than this: > > > tag:example.org,2007:/the/only/useful/thing/here > 2007-12-12T12:12:12Z > > > Or even just this: > > > tag:example.org,2007:/the/only/useful/thing/here > Two things: 1: what you deleted was an entry. 2: you might want to know the properties of the entry that was deleted, not just its name. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 09:51:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9iSt-0003s2-DF for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:51:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9iSt-0003K1-0M for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:51:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01Ecidd061625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 07:38:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01EciFX061624; Tue, 1 Jan 2008 07:38:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01Ecinn061618 for ; Tue, 1 Jan 2008 07:38:44 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 23441DD633 for ; Tue, 1 Jan 2008 14:38:43 +0000 (UTC) Message-ID: <477A5074.8060908@dehora.net> Date: Tue, 01 Jan 2008 14:38:44 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "'Atom-Syntax'" Subject: Re: Tombstones References: <47562422.40408@gmail.com> <000001c8390f$ab7bd050$2501a8c0@Junk> In-Reply-To: <000001c8390f$ab7bd050$2501a8c0@Junk> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Brian Smith wrote: > How do you suggest dealing with inappropriate data in the atom:id > element? Examples: > > id='http://example.org/blog/i-am-so-high-at-work-right-now'/> > id='http://example.org/blog/im-getting-divorced-and-marrying-my-secretar > y'/> > > > (I've seen very similar entries posted and then deleted from actual > feeds.) > > This still discloses a significant amount of information that the feed > author doesn't want disclosed after deleting the entry, and this kind of > disclosure is something that a non-technical blogger would not expect. Unfortunately, this makes it seem that decentralization and caching are bugs, not features. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 09:54:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9iW5-0007PT-OL for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:54:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9iW5-0003Lg-Ai for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 09:54:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01EgXV0061794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 07:42:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01EgXfm061793; Tue, 1 Jan 2008 07:42:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01EgXhb061786 for ; Tue, 1 Jan 2008 07:42:33 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 9CC55DD606 for ; Tue, 1 Jan 2008 14:42:32 +0000 (UTC) Message-ID: <477A5159.2080708@dehora.net> Date: Tue, 01 Jan 2008 14:42:33 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "'Atom-Syntax'" Subject: Re: Feed Paging for Efficient Feed Synchronization References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com> <002001c8388a$90c65b20$2501a8c0@Junk> <475A288F.10301@gmail.com> <003a01c839ae$bac27ce0$2101a8c0@Junk> In-Reply-To: <003a01c839ae$bac27ce0$2101a8c0@Junk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Brian Smith wrote: > James M Snell wrote: >> Excellent points. The primary issue for me is the fact that >> the set of entries we're synchronizing has to remain stable >> throughout the synchronization process or else we risk race >> conditions and a variety of possible conflicts. If the >> stability of the pages can be reasonably guaranteed then >> paging is acceptable. > > I'm pretty sure I agree with you, but please define "stable". Look at how twitter implements paging (it's not using atom, but the concept stands). The content on page=2 of your twitter changes as a function of new posts on the home page, although the entries themselves are uniquely identified. That's not stable. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 13:06:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9lVA-0002eq-2c for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 13:06:08 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9lV8-0004oQ-Ie for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 13:06:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01Hkr4I069202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 10:46:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01Hkrsi069201; Tue, 1 Jan 2008 10:46:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01HkpU5069194 for ; Tue, 1 Jan 2008 10:46:52 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so3373011rvf.34 for ; Tue, 01 Jan 2008 09:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=biSiD6472FuVSFNgi40/LWhVt/VXMHnrrTqdy7p3g/A=; b=MDQ67QbWa6v5g/ZNnLs4QJWrHW8k86hdr3y2TrwEOBi75c6e4bxQV7ez17qYbFWjLicYh2cvtLnWtPnxtbmMmqheAVpORTp7T1cVbIkJ37BnXzpU+TTVDfJ/AJmEvmI2ebFD9BmwrLaybtt6Yds7TNZ+5Z//c4puimz0jqPTNFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=cMHzuBlIiF60hM3TSVkdttT+sjHjqEMh0Hd1hEpJWpUN1iWHljOgu9seYn4nWiuc1lKvCJUr8k48LMDScdl6f+eV0Lf/lvPfH6y0XsThI2OYgXgOEdV6IpXaW+bkt5tK+XL/vfWEbGarC600I4L+E7VWXFqGhyShMN52Xp3Txkc= Received: by 10.140.136.6 with SMTP id j6mr6891982rvd.50.1199209611470; Tue, 01 Jan 2008 09:46:51 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id c14sm23561573rvf.19.2008.01.01.09.46.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jan 2008 09:46:50 -0800 (PST) Message-ID: <477A7C87.4090906@gmail.com> Date: Tue, 01 Jan 2008 09:46:47 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: Joe Gregorio , David Powell , Steven Lees , Mark Nottingham , Atom Syntax Subject: Re: Tombstones References: <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> In-Reply-To: <477A4F49.5070900@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Bill de hOra wrote: > James M Snell wrote: > >> That said, what is the value of reusing atom:entry in this case? >> [snip] > > Two things: > > 1: what you deleted was an entry. > Ok, but why does that mean we have to use atom:entry to represent the thing that no longer exists? > 2: you might want to know the properties of the entry that was deleted, > not just its name. > There's no reason this data could not be added as children of the x:deleted element. Keep in mind that atom:entry has minimum content requirements so you'd either have to keep around a minimum amount of metadata or start passing around useless cruft. - James > cheers > Bill > > > From owner-atom-syntax@mail.imc.org Tue Jan 01 13:32:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9luY-00049N-DN for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 13:32:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9luX-00050l-Mx for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 13:32:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01IIHDc070493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 11:18:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01IIHK2070490; Tue, 1 Jan 2008 11:18:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01IIEsQ070442 for ; Tue, 1 Jan 2008 11:18:15 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so3379921rvf.34 for ; Tue, 01 Jan 2008 10:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=7luSIUQ/51sx3TWr/FWgvBHf3yb3JDpt1c6tFlHWgL8=; b=mpcbTPTs42ZzUY2KUgZAPwuKKsH/ZhJHkU4Z/Qv9Y3/s0MTVtzqxW5m3mRYxOvJ4ZbQuFsmXIUqUDEY8O8VxtVIA+smsIuLDgCJtcv/99u9Ysbb27Lrt81xFjsoYV2WUoiMbh8xQ58p48AlgFyiT5+8nBX9aWXt+xbn/WvbbUkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=J7Xt6ATgEuwrQY3XGOPHN8L9glTIWag1hpffC8LPnIMM1efLDPS83y6C9zoJ94/yFSTvdg5CBL4QtntK1TaGGnfV9lIL58A6BgvvQzBbKzmN1gZat/x/0LYlyxJyaAkG7ogTTb80E5hjENKm5oQfKnZ/x3tQQoyC90nRThwCIro= Received: by 10.141.115.6 with SMTP id s6mr6926531rvm.47.1199211494422; Tue, 01 Jan 2008 10:18:14 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id g22sm21258068rvb.5.2008.01.01.10.18.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jan 2008 10:18:13 -0800 (PST) Message-ID: <477A83E3.10905@gmail.com> Date: Tue, 01 Jan 2008 10:18:11 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Peter Keane CC: "'Atom-Syntax'" Subject: Re: OAI-ORE Resource Map Implementation in Atom References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Although I haven't had the time to really sit down an analyze this in depth, at first glance it definitely looks interesting and fairly sane. - James Peter Keane wrote: > > Hi Folks- > > Open Archives Initiative Object Reuse and Exchange figures to be a VERY > important standard in the digital library/archives world. From the > documentation: > > "OAI-ORE defines standards for the description and exchange of > aggregations of Web resources. the OAI-ORE introduces the notion of a > Resource Map, which is a specialization of a named graph that asserts a > finite set of resources (the Aggregated Resources), their types, > intra-relationships, and relationships with resources external to this > finite set (the external resources). A Resource Map Document is a > machine-readable representation of a Resource Map. Although multiple > serializations of Resource Maps are possible, the initial serialization > is done using the Atom Syndication Format [RFC4287]." > > I'll be very curious to know what the Atom-erati think about the > Resource Map Implentation in Atom: > (http://www.openarchives.org/ore/0.1/atom-implementation). > > It looks to me to be a well-considered and thorough implementation of > the Atom Syndication Format in an area well-outside the blogging domain. > Perhaps this is a (welcome and anticipated) sign of the power and > utility of Atom/AtomPub? > > -Peter Keane > daseproject.org > > From owner-atom-syntax@mail.imc.org Tue Jan 01 15:15:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nWc-00079v-Lt for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 15:15:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9nWb-00066D-8F for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 15:15:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01K02us074351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 13:00:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01K026I074350; Tue, 1 Jan 2008 13:00:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01K01Ml074344 for ; Tue, 1 Jan 2008 13:00:01 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 8B727DD57C for ; Tue, 1 Jan 2008 20:00:00 +0000 (UTC) Message-ID: <477A9BC1.4000407@dehora.net> Date: Tue, 01 Jan 2008 20:00:01 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tombstones References: <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> In-Reply-To: <477A7C87.4090906@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b James M Snell wrote: > Bill de hOra wrote: >> James M Snell wrote: >> >>> That said, what is the value of reusing atom:entry in this case? >>> [snip] >> Two things: >> >> 1: what you deleted was an entry. >> > > Ok, but why does that mean we have to use atom:entry to represent the > thing that no longer exists? Because as I said, the thing was an Entry. But we're moving the discussion about a bit. If we're talking about hard delete, all you need is 410 gone, no markup needed. For soft deletes (or audit, or history, or compliance, or who knows), why not represent the deleted Entry with an Entry? It seems the most natural thing. >> 2: you might want to know the properties of the entry that was deleted, >> not just its name. >> > > There's no reason this data could not be added as children of the > x:deleted element. Keep in mind that atom:entry has minimum content > requirements so you'd either have to keep around a minimum amount of > metadata or start passing around useless cruft. It's still cruft. Apologies tho'; I know I came to this thread late, but I'm not seeing the reason to introduce a new type (aka 'tombstone'), insofar as adding a new type is a big deal. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 15:30:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nl2-0007UN-Bu for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 15:30:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9nl1-0006H0-Vu for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 15:30:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01KFETs075160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 13:15:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01KFEjH075159; Tue, 1 Jan 2008 13:15:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01KFDsb075153 for ; Tue, 1 Jan 2008 13:15:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so950906anc.44 for ; Tue, 01 Jan 2008 12:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=UwMgrQdIlhI340g7Wi7sJkxFQOoXexrpl6H9rWrYsnk=; b=udggLzIbFWBj0M7/EwUJauLzWf1ajm1MCjGi/VTRMc3uXCtLCJiiK75o6YSscIPPSHuipPHPewjCLlN/obWfGspM0QrzDwwgrbsPl+k6TtJg/KQDPoNnSY5TDylGcU29zKHOMkJAMgTd5EWkk+uLZsuQOyqGs93F9Uk9tgcIZBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=eqn0P4QYp767NbrDUYOQIy6DBZ9kDnNFx2P68uRxPA+o1lRZhO0ZwjYHFvW3FC8rBB5mTyNor4fr1+nA/rPG81Wlu5r0fS96z39tYGqWws5xIjMhmAsWcWbZVN/uUcMSJzfwxyq1FSw9UXCD2u/2idyX+/KPBy7F5wlbfgD6/4g= Received: by 10.100.232.13 with SMTP id e13mr21560880anh.61.1199218513467; Tue, 01 Jan 2008 12:15:13 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 39sm8384631hse.7.2008.01.01.12.15.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jan 2008 12:15:12 -0800 (PST) Message-ID: <477A9F4E.8040300@gmail.com> Date: Tue, 01 Jan 2008 12:15:10 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: Atom Syntax Subject: Re: Tombstones References: <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> In-Reply-To: <477A9BC1.4000407@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 I think I've covered the reasons why I think atom:entry is inappropriate well enough that there's no reason to go back into it. If you haven't yet had the time to go back through the thread (which would be understandable since it's a pretty long thread), I would encourage you to go back and read the points I've made thus far. - James Bill de hOra wrote: > [snip] > > It's still cruft. > > Apologies tho'; I know I came to this thread late, but I'm not seeing > the reason to introduce a new type (aka 'tombstone'), insofar as adding > a new type is a big deal. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Tue Jan 01 15:41:07 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nv9-0000EZ-8g for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 15:41:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9nv6-0006Op-V0 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 15:41:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01KOqro075614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 13:24:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01KOq2U075613; Tue, 1 Jan 2008 13:24:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with SMTP id m01KOo4M075604 for ; Tue, 1 Jan 2008 13:24:51 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 Jan 2008 20:24:49 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp045) with SMTP; 01 Jan 2008 21:24:49 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX18rb3g5ZN8row+QERFwsoCkwdh1oFgCTCAq8FWt4x Uh7dLh6jD47VIa Date: Tue, 1 Jan 2008 21:24:48 +0100 From: Aristotle Pagaltzis To: Atom Syntax Subject: Re: Tombstones Message-ID: <20080101202448.GL564@klangraum> Mail-Followup-To: Atom Syntax References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477A9BC1.4000407@dehora.net> User-Agent: Mutt/1.5.16 (2007-06-09) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad * Bill de hOra [2008-01-01 21:10]: > If we're talking about hard delete, all you need is 410 gone, > no markup needed. Eh? How is a feed reader supposed to know that an Entry (which might not even have had a permalink) was deleted from a feed vs just fell off the bottom? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Jan 01 17:55:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9q1b-0005qD-Fz for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 17:55:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9q1Z-0007uq-Vf for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 17:55:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01MeUUi082065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 15:40:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01MeURT082064; Tue, 1 Jan 2008 15:40:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01MeUnE082058 for ; Tue, 1 Jan 2008 15:40:30 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 3AE07DDBB4 for ; Tue, 1 Jan 2008 22:40:29 +0000 (UTC) Message-ID: <477AC15F.1010104@dehora.net> Date: Tue, 01 Jan 2008 22:40:31 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tombstones References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> In-Reply-To: <20080101202448.GL564@klangraum> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Aristotle Pagaltzis wrote: > * Bill de hOra [2008-01-01 21:10]: >> If we're talking about hard delete, all you need is 410 gone, >> no markup needed. > > Eh? How is a feed reader supposed to know that an Entry (which > might not even have had a permalink) was deleted from a feed vs > just fell off the bottom? 1: If it doesn't have a permalink (or a link at all), it's not on the web; in all seriousness, why do we care about it? 2: why does it matter, the difference between falling off the bottom and being deleted? cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 18:43:29 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9qld-0005xI-M2 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 18:43:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9qld-00008x-9b for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 18:43:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01NVgvm083727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 16:31:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01NVgGA083726; Tue, 1 Jan 2008 16:31:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01NVf4R083720 for ; Tue, 1 Jan 2008 16:31:42 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id A4930DDC19 for ; Tue, 1 Jan 2008 23:31:40 +0000 (UTC) Message-ID: <477ACD5E.5000704@dehora.net> Date: Tue, 01 Jan 2008 23:31:42 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tombstones References: <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <477A9F4E.8040300@gmail.com> In-Reply-To: <477A9F4E.8040300@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 James M Snell wrote: > I think I've covered the reasons why I think atom:entry is inappropriate > well enough that there's no reason to go back into it. If you haven't > yet had the time to go back through the thread (which would be > understandable since it's a pretty long thread), I would encourage you > to go back and read the points I've made thus far. I already went through the thread. cheers Bill > - James > > Bill de hOra wrote: >> [snip] >> >> It's still cruft. >> >> Apologies tho'; I know I came to this thread late, but I'm not seeing >> the reason to introduce a new type (aka 'tombstone'), insofar as adding >> a new type is a big deal. >> >> cheers >> Bill >> >> From owner-atom-syntax@mail.imc.org Tue Jan 01 19:08:05 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9r9Q-00041p-Sf for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 19:08:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9r9Q-0000PB-B7 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 19:08:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m01NsLP2084367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 16:54:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m01NsLc9084366; Tue, 1 Jan 2008 16:54:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with SMTP id m01NsHZ0084355 for ; Tue, 1 Jan 2008 16:54:20 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 Jan 2008 23:54:17 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp003) with SMTP; 02 Jan 2008 00:54:17 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX18UoBMzXDUUwMp0V3NqdAHqra7Y8Hr5HdoEmLomnz 7yHbHDbttB+leM Date: Wed, 2 Jan 2008 00:54:16 +0100 From: Aristotle Pagaltzis To: Atom Syntax Subject: Re: Tombstones Message-ID: <20080101235416.GN564@klangraum> Mail-Followup-To: Atom Syntax References: <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <477AC15F.1010104@dehora.net> User-Agent: Mutt/1.5.16 (2007-06-09) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m01NsLP2084367 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d * Bill de hOra [2008-01-01 23:55]: > 1: If it doesn't have a permalink (or a link at all), it's not > on the web; in all seriousness, why do we care about it? Doesn=E2=80=99t matter. I preemptively pointed that out just to say that even if you wanted to propose that feed readers poll every permalink on every feed poll (), that wouldn=E2=80=99t even work. > 2: why does it matter, the difference between falling off the > bottom and being deleted? =E2=80=99Cause the original use case here is comments feed and comment spam that slipped through. And that reminds that 401 is further useless, because the permalink of such Entries is distinguished from the blog post permalink only through a fragment identifier, so they have no public identity in HTTP separate from the blog post itself. Sorry, 401 doesn=E2=80=99t cut it. Communicating deletion requires the Atom ID, not the permalink, and a timestamp, and that=E2=80=99s all that should be required, which disqualifies the use of atom:entry as the vehicle. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Jan 01 20:02:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9s0Q-0006mc-3c for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:02:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9s0P-0001EH-Me for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:02:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m020jZMu086216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 17:45:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m020jZad086215; Tue, 1 Jan 2008 17:45:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m020jVwO086201 for ; Tue, 1 Jan 2008 17:45:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so3456205rvf.34 for ; Tue, 01 Jan 2008 16:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=pSgn2CwQI9FwB13nDhSb7QaKGI0arMoA5+yaWk22V1U=; b=ZUU2tjd6cnP3UV5q0BckTYidztR26cTdcl3qKeaxAQud6QH9uEhn++ZH3uNBjpWmUD4TS6DOyQ0sC+DRDkOtsIBK4SNiOXPRtAkBexQNZx4vo+y/EP3t/+I6vvTrQ1w8TDYuMbUp7bGBf81EXlgMRLGsa3p4B1/lILeUCWAPPLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=L3gSIK9ti3N2yO3mky6Ha6udlYEklIb+GyyKEFjrdRsL80e3VCX+jAiptbNZf6IHXduoeBITy0rb7RO+GHTPA9gCHsXlJ9Usjt6doIq72J1RkByHmriuLBk9aUFba+c1DvTB1NNDl75IwwlmcidHJOqHpqNSGD0YHQ+PZ6/MiA8= Received: by 10.141.185.3 with SMTP id m3mr7012071rvp.167.1199234731266; Tue, 01 Jan 2008 16:45:31 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id g31sm4491587rvb.7.2008.01.01.16.45.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jan 2008 16:45:30 -0800 (PST) Message-ID: <477ADEA8.1040307@gmail.com> Date: Tue, 01 Jan 2008 16:45:28 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: Atom Syntax Subject: Re: Tombstones References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> In-Reply-To: <477AC15F.1010104@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Bill de hOra wrote: > [snip] > 1: If it doesn't have a permalink (or a link at all), it's not on the > web; in all seriousness, why do we care about it? > Whether the thing has a permalink or not is irrelevant. We're talking about having a mechanism of indicating when an entry is no longer part of a collection or a feed. It could be that the entry still exists in some form or other somewhere else, but how do I know that the thing is no longer part of a specific feed? > 2: why does it matter, the difference between falling off the bottom and > being deleted? > Define "falling off". If the feed is paged, does "falling off" mean we'll find the entry on the next or previous page? What if the feed only shows the 100 most recent items? What should I do with my local copy of the entry if suddenly the entry no longer appears in the feed? There is a significant difference between falling off and being deleted. - James > cheers > Bill > > From owner-atom-syntax@mail.imc.org Tue Jan 01 20:03:38 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9s1C-00071g-16 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:03:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9s1B-0001Em-BP for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:03:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m020mAJ8086496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 17:48:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m020mAws086495; Tue, 1 Jan 2008 17:48:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with SMTP id m020m82h086487 for ; Tue, 1 Jan 2008 17:48:09 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 Jan 2008 00:48:08 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp012) with SMTP; 02 Jan 2008 01:48:08 +0100 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX18Ei5wQx+UEc5Qp18foAKaHNRC4Dq1Zpu1GykLvqL E7MdPmah1U6W2T Date: Wed, 2 Jan 2008 01:48:07 +0100 From: Aristotle Pagaltzis To: Atom Syntax Subject: Re: Tombstones Message-ID: <20080102004807.GO564@klangraum> Mail-Followup-To: Atom Syntax References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <20080101235416.GN564@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080101235416.GN564@klangraum> User-Agent: Mutt/1.5.16 (2007-06-09) X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m020mAJ8086496 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Err, I missed two bits while writing: * Aristotle Pagaltzis [2008-01-02 01:05]: > Doesn=E2=80=99t matter. I preemptively pointed that out just to say > that even if you wanted to propose that feed readers poll every > permalink on every feed poll (), that wouldn=E2=80=99t even work. ^ (obviously absurd) > And that reminds that 401 is further useless, because the > permalink of such Entries is distinguished from the blog post ^ commonly > permalink only through a fragment identifier, so they have no > public identity in HTTP separate from the blog post itself. >=20 > Sorry, 401 doesn=E2=80=99t cut it. Communicating deletion requires the > Atom ID, not the permalink, and a timestamp, and that=E2=80=99s all > that should be required, which disqualifies the use of > atom:entry as the vehicle. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Jan 01 20:47:42 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9shq-0000vl-4m for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:47:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9shp-0001pO-Mw for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:47:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m021XZ99088100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 18:33:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m021XZtF088098; Tue, 1 Jan 2008 18:33:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m021XYwr088092 for ; Tue, 1 Jan 2008 18:33:34 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 74873DD47B for ; Wed, 2 Jan 2008 01:33:33 +0000 (UTC) Message-ID: <477AE9F0.1070506@dehora.net> Date: Wed, 02 Jan 2008 01:33:36 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tombstones References: <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <20080101235416.GN564@klangraum> In-Reply-To: <20080101235416.GN564@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m021XZ99088100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Aristotle Pagaltzis wrote: > * Bill de hOra [2008-01-01 23:55]: >> 1: If it doesn't have a permalink (or a link at all), it's not >> on the web; in all seriousness, why do we care about it? >=20 > Doesn=E2=80=99t matter. I preemptively pointed that out just to say tha= t > even if you wanted to propose that feed readers poll every > permalink on every feed poll (), that wouldn=E2=80=99t even work. >=20 >> 2: why does it matter, the difference between falling off the >> bottom and being deleted? >=20 > =E2=80=99Cause the original use case here is comments feed and comment > spam that slipped through. That honestly doesn't explain it. The comment was in the feed, then it=20 was not. Why do you need to say why it's not there anymore? > And that reminds that 401 is further useless, because the > permalink of such Entries is distinguished from the blog post > permalink only through a fragment identifier, so they have no > public identity in HTTP separate from the blog post itself. Right, there is a lot of stupid blog code about. > Sorry, 401 doesn=E2=80=99t cut it. Communicating deletion requires the > Atom ID, not the permalink, and a timestamp, and that=E2=80=99s all tha= t > should be required, which disqualifies the use of atom:entry as > the vehicle. "disqualifies" - sorry, I'm not convinced. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 20:49:32 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9sjc-0004NW-F4 for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:49:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9sjc-0001qb-1Q for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 20:49:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m021aFf8088187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 18:36:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m021aFdZ088186; Tue, 1 Jan 2008 18:36:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m021aFr0088179 for ; Tue, 1 Jan 2008 18:36:15 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 86D6FDDC11 for ; Wed, 2 Jan 2008 01:36:14 +0000 (UTC) Message-ID: <477AEA91.4010401@dehora.net> Date: Wed, 02 Jan 2008 01:36:17 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tombstones References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> In-Reply-To: <477ADEA8.1040307@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 James M Snell wrote: > > Bill de hOra wrote: >> [snip] >> 1: If it doesn't have a permalink (or a link at all), it's not on the >> web; in all seriousness, why do we care about it? >> > > Whether the thing has a permalink or not is irrelevant. We're talking > about having a mechanism of indicating when an entry is no longer part > of a collection or a feed. It could be that the entry still exists in > some form or other somewhere else, but how do I know that the thing is > no longer part of a specific feed? It's not in the feed anymore - but first perhaps define "feed". >> 2: why does it matter, the difference between falling off the bottom and >> being deleted? >> > > Define "falling off". If the feed is paged, does "falling off" mean > we'll find the entry on the next or previous page? What if the feed > only shows the 100 most recent items? What should I do with my local > copy of the entry if suddenly the entry no longer appears in the feed? > > There is a significant difference between falling off and being deleted. I didn't say there wasn't, I asked it be explained why the difference matters in this case, to the extent we need a new type and new markup. cheers Bill From owner-atom-syntax@mail.imc.org Tue Jan 01 22:07:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9twq-0006aM-3I for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 22:07:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9twn-0002qZ-OK for atompub-archive@lists.ietf.org; Tue, 01 Jan 2008 22:07:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m022qdvC092066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 19:52:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m022qdg3092065; Tue, 1 Jan 2008 19:52:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m022qcLE092059 for ; Tue, 1 Jan 2008 19:52:38 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=nlruJYF62TR1/WdtA9CZqmHfpUUB9rV75mzhQwKpHciF2YhLcEtbs YLw8IYJqL6mfG+kDhfUjcqcjm5M9SSr5UpFscaFVYt+f1MzOVwI7h UE07z2cbc6gw0tbm5O/LN7Z9LEE+IfzHOipN6ASEZc8Fr6vvcxc8T JQMfYd92g30g=; Received: from wb9-a.mail.utexas.edu ([128.83.126.150]) by ironman.mail.utexas.edu with ESMTP; 01 Jan 2008 20:52:38 -0600 Received: (qmail 678 invoked from network); 2 Jan 2008 02:52:37 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb9.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 2 Jan 2008 02:52:37 -0000 Date: Tue, 1 Jan 2008 20:52:37 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: Bill de hOra cc: Atom Syntax Subject: Re: Tombstones In-Reply-To: <477AEA91.4010401@dehora.net> Message-ID: References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Re: tombstones, I'll just throw in a mention if the OAI-ORE work (Open Archives Initiative Object Reuse and Exchange - http://www.openarchives.org/ore/0.1/atom-implementation) which figures to be very important in archiving/preservation, etc. and serializes a "Resource Map" (named graphs that represent aggregations of Web Resources) and serializes them using Atom. The issue of tombstones will be big and the previous discussion around "soft-deletes" (deletions that can be resurrected or perhaps used in various client-determined ways) will be a significant use case. I feel like Joe Gregorio's suggestion of two feeds (http://www.mail-archive.com/atom-syntax@imc.org/msg01092.html) feels like the best solution for this case. (since those deletes really ARE of type atom:entry -- a new type does not smell quite right). And why can't atom:category be used to indicate that an entry has been deleted? (In fact, perhaps a few different categories for the different kinds of "deleted"). -peter keane > > James M Snell wrote: >> >> Bill de hOra wrote: >>> [snip] >>> 1: If it doesn't have a permalink (or a link at all), it's not on the >>> web; in all seriousness, why do we care about it? >>> >> >> Whether the thing has a permalink or not is irrelevant. We're talking >> about having a mechanism of indicating when an entry is no longer part >> of a collection or a feed. It could be that the entry still exists in >> some form or other somewhere else, but how do I know that the thing is >> no longer part of a specific feed? > > It's not in the feed anymore - but first perhaps define "feed". > > >>> 2: why does it matter, the difference between falling off the bottom and >>> being deleted? >>> >> >> Define "falling off". If the feed is paged, does "falling off" mean >> we'll find the entry on the next or previous page? What if the feed >> only shows the 100 most recent items? What should I do with my local >> copy of the entry if suddenly the entry no longer appears in the feed? >> >> There is a significant difference between falling off and being deleted. > > I didn't say there wasn't, I asked it be explained why the difference matters > in this case, to the extent we need a new type and new markup. > > cheers > Bill > From owner-atom-syntax@mail.imc.org Wed Jan 02 00:14:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9vvm-0005sL-5Q for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 00:14:18 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9vvl-0003zo-Dr for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 00:14:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m024vuS7096054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 21:57:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m024vu5B096052; Tue, 1 Jan 2008 21:57:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m024vsD0096046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jan 2008 21:57:55 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6D71523E497; Tue, 1 Jan 2008 23:57:52 -0500 (EST) Cc: Bill de hOra , Atom Syntax Message-Id: From: Mark Nottingham To: Peter Keane In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Tombstones Date: Wed, 2 Jan 2008 15:57:50 +1100 References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac I still don't understand the pushback that people have against a new feed-level element not "smelling right." Atom explicitly allows extensions there. Cheers, On 02/01/2008, at 1:52 PM, Peter Keane wrote: > > Re: tombstones, I'll just throw in a mention if the OAI-ORE work > (Open Archives Initiative Object Reuse and Exchange - http://www.openarchives.org/ore/0.1/atom-implementation) > which figures to be very important in archiving/preservation, etc. > and serializes a "Resource Map" (named graphs that represent > aggregations of Web Resources) and serializes them using Atom. > > The issue of tombstones will be big and the previous discussion > around "soft-deletes" (deletions that can be resurrected or perhaps > used in various client-determined ways) will be a significant use > case. I feel like Joe Gregorio's suggestion of two feeds > (http://www.mail-archive.com/atom-syntax@imc.org/msg01092.html) > feels like the best solution for this case. (since those deletes > really ARE of type atom:entry -- a new type does not smell quite > right). > > And why can't atom:category be used to indicate that an entry has > been deleted? (In fact, perhaps a few different categories for the > different kinds of "deleted"). > > -peter keane > >> >> James M Snell wrote: >>> Bill de hOra wrote: >>>> [snip] >>>> 1: If it doesn't have a permalink (or a link at all), it's not on >>>> the >>>> web; in all seriousness, why do we care about it? >>> Whether the thing has a permalink or not is irrelevant. We're >>> talking >>> about having a mechanism of indicating when an entry is no longer >>> part >>> of a collection or a feed. It could be that the entry still >>> exists in >>> some form or other somewhere else, but how do I know that the >>> thing is >>> no longer part of a specific feed? >> >> It's not in the feed anymore - but first perhaps define "feed". >> >> >>>> 2: why does it matter, the difference between falling off the >>>> bottom and >>>> being deleted? >>> Define "falling off". If the feed is paged, does "falling off" mean >>> we'll find the entry on the next or previous page? What if the feed >>> only shows the 100 most recent items? What should I do with my >>> local >>> copy of the entry if suddenly the entry no longer appears in the >>> feed? >>> There is a significant difference between falling off and being >>> deleted. >> >> I didn't say there wasn't, I asked it be explained why the >> difference matters in this case, to the extent we need a new type >> and new markup. >> >> cheers >> Bill >> > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jan 02 00:56:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9wah-0007gm-3r for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 00:56:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9wae-0004On-Nn for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 00:56:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m025fDRP097283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 22:41:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m025fDD1097282; Tue, 1 Jan 2008 22:41:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m025fAG0097276 for ; Tue, 1 Jan 2008 22:41:12 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so3518755rvf.34 for ; Tue, 01 Jan 2008 21:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=nVPZEN3yqPQ+Z+tkBpxspUnoD3+QZsG1TmIdcSLo83Q=; b=s9fdeLyLYk+UH1g4HCj0aRYs9ZsDUoZdZi+DFvyFe1QTiEEC1ZnssMNzg3ZEtRhWcFrrWB8rUdPNdMjq+XX3qfVcrpJuzH79om7fFlqVGpcfKgA4U1QWY0UK2tI2xL9OiUgxIZmhcDxsBLQZ6zIXk5U5gU2Xc3AQBE+w0WZnrxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=iSiziIXvpyrgB4zjGIwjRIVWqJiiI/1k+kC15Kg8W/YZAh5Aa6w5/VLNefYXU8Sy9hCvNh2dNlSp93CPR9FGwcMo+mrHCsvNJhSU/Df1mVKCG0DHzTusxzyMABmtctljpLXAdOCdiMk2NP6KRpohDmMpPYdZJCD3N0RGQHTWvE4= Received: by 10.141.63.20 with SMTP id q20mr4000552rvk.258.1199252470158; Tue, 01 Jan 2008 21:41:10 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id f34sm11908630rvb.3.2008.01.01.21.41.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Jan 2008 21:41:09 -0800 (PST) Message-ID: <477B23F3.1010003@gmail.com> Date: Tue, 01 Jan 2008 21:41:07 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Mark Nottingham CC: Peter Keane , Bill de hOra , Atom Syntax Subject: Re: Tombstones References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 +1. I've asked several times why using atom:entry would be better than x:deleted and I have yet to see a clear, coherent argument. - James Mark Nottingham wrote: > > I still don't understand the pushback that people have against a new > feed-level element not "smelling right." Atom explicitly allows > extensions there. > > Cheers, > > > On 02/01/2008, at 1:52 PM, Peter Keane wrote: > >> >> Re: tombstones, I'll just throw in a mention if the OAI-ORE work (Open >> Archives Initiative Object Reuse and Exchange - >> http://www.openarchives.org/ore/0.1/atom-implementation) which figures >> to be very important in archiving/preservation, etc. and serializes a >> "Resource Map" (named graphs that represent aggregations of Web >> Resources) and serializes them using Atom. >> >> The issue of tombstones will be big and the previous discussion around >> "soft-deletes" (deletions that can be resurrected or perhaps used in >> various client-determined ways) will be a significant use case. I >> feel like Joe Gregorio's suggestion of two feeds >> (http://www.mail-archive.com/atom-syntax@imc.org/msg01092.html) feels >> like the best solution for this case. (since those deletes really ARE >> of type atom:entry -- a new type does not smell quite right). >> >> And why can't atom:category be used to indicate that an entry has been >> deleted? (In fact, perhaps a few different categories for the >> different kinds of "deleted"). >> >> -peter keane >> >>> >>> James M Snell wrote: >>>> Bill de hOra wrote: >>>>> [snip] >>>>> 1: If it doesn't have a permalink (or a link at all), it's not on the >>>>> web; in all seriousness, why do we care about it? >>>> Whether the thing has a permalink or not is irrelevant. We're talking >>>> about having a mechanism of indicating when an entry is no longer part >>>> of a collection or a feed. It could be that the entry still exists in >>>> some form or other somewhere else, but how do I know that the thing is >>>> no longer part of a specific feed? >>> >>> It's not in the feed anymore - but first perhaps define "feed". >>> >>> >>>>> 2: why does it matter, the difference between falling off the >>>>> bottom and >>>>> being deleted? >>>> Define "falling off". If the feed is paged, does "falling off" mean >>>> we'll find the entry on the next or previous page? What if the feed >>>> only shows the 100 most recent items? What should I do with my local >>>> copy of the entry if suddenly the entry no longer appears in the feed? >>>> There is a significant difference between falling off and being >>>> deleted. >>> >>> I didn't say there wasn't, I asked it be explained why the difference >>> matters in this case, to the extent we need a new type and new markup. >>> >>> cheers >>> Bill >>> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Wed Jan 02 01:51:21 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9xRh-0007cq-FC for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 01:51:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9xRf-00053e-5Y for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 01:51:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m026bTXA098976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 23:37:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m026bTU9098975; Tue, 1 Jan 2008 23:37:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m026bSjx098969 for ; Tue, 1 Jan 2008 23:37:28 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=Vb99zcZWuBOzQkF35ERD5cHNKD+tkqvxZwQaJ45ReeF++xb2kdYE3 XYW0PHscCYS1QY6xYak6R+q+CMKUvMtMAAwq+A3TvuPrB4W432C3f K1VGko2isfIvMq+TyNTL7vU9J/LSebKSygAJYdbtwN3aPhdIcAyIV wsrCauTZLJg4=; Received: from wb6-a.mail.utexas.edu ([128.83.126.144]) by ironman.mail.utexas.edu with ESMTP; 02 Jan 2008 00:37:28 -0600 Received: (qmail 77153 invoked from network); 2 Jan 2008 06:37:27 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb6.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 2 Jan 2008 06:37:27 -0000 Date: Wed, 2 Jan 2008 00:37:27 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: Mark Nottingham , Bill de hOra , Atom Syntax Subject: Re: Tombstones In-Reply-To: <477B23F3.1010003@gmail.com> Message-ID: References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f I'll certainly defer to the judgement to folks who have a better understanding of the nuances of Atom, but my perspective is that of a librarian/programmer interesting in Atom in the broadest and most non-blogging-oriented domains (as an aside I think the strength of the spec comes from a set of well-understood uses cases in a particular domain -- I just want to see how effective it might be outside of that domain). Feed-level elements are of two types: metadata about the feed, and items in a "set" of things. Throwing a new type in the mix is really a huge change -- if it's about the feed, OK (but clearly a tombstone is an entity of it's own and not metadata about the feed), otherwise you are creating a second "set" and there goes the beauty of Atom (and up goes the cognitive load -- at least at the conceptual level). Perhaps it comes down to: are tombstones a significant resource (I say yes)? And if so, they need to have a URI. Also, a new type seems to create a tighter coupling with the client than is ideal -- why must I (the client or client implementor) need to think about a new type? I'd much prefer an atom:category element that flagged an entry as "deleted" with an expectation that it'd hang around for some period of time (soft-delete) and at some indeterminate point fall off the feed (hard-deleted) if/when the feed publisher so chooses. It just seems more natural to deal with a deleted entry like that -- a new type seems to me to presuppose an understanding of the possible use cases which is simply impossible at this point. --peter keane On Tue, 1 Jan 2008, James M Snell wrote: > > +1. I've asked several times why using atom:entry would be better than > x:deleted and I have yet to see a clear, coherent argument. > > - James > > Mark Nottingham wrote: >> >> I still don't understand the pushback that people have against a new >> feed-level element not "smelling right." Atom explicitly allows >> extensions there. >> >> Cheers, >> >> >> On 02/01/2008, at 1:52 PM, Peter Keane wrote: >> >>> >>> Re: tombstones, I'll just throw in a mention if the OAI-ORE work (Open >>> Archives Initiative Object Reuse and Exchange - >>> http://www.openarchives.org/ore/0.1/atom-implementation) which figures >>> to be very important in archiving/preservation, etc. and serializes a >>> "Resource Map" (named graphs that represent aggregations of Web >>> Resources) and serializes them using Atom. >>> >>> The issue of tombstones will be big and the previous discussion around >>> "soft-deletes" (deletions that can be resurrected or perhaps used in >>> various client-determined ways) will be a significant use case. I >>> feel like Joe Gregorio's suggestion of two feeds >>> (http://www.mail-archive.com/atom-syntax@imc.org/msg01092.html) feels >>> like the best solution for this case. (since those deletes really ARE >>> of type atom:entry -- a new type does not smell quite right). >>> >>> And why can't atom:category be used to indicate that an entry has been >>> deleted? (In fact, perhaps a few different categories for the >>> different kinds of "deleted"). >>> >>> -peter keane >>> >>>> >>>> James M Snell wrote: >>>>> Bill de hOra wrote: >>>>>> [snip] >>>>>> 1: If it doesn't have a permalink (or a link at all), it's not on the >>>>>> web; in all seriousness, why do we care about it? >>>>> Whether the thing has a permalink or not is irrelevant. We're talking >>>>> about having a mechanism of indicating when an entry is no longer part >>>>> of a collection or a feed. It could be that the entry still exists in >>>>> some form or other somewhere else, but how do I know that the thing is >>>>> no longer part of a specific feed? >>>> >>>> It's not in the feed anymore - but first perhaps define "feed". >>>> >>>> >>>>>> 2: why does it matter, the difference between falling off the >>>>>> bottom and >>>>>> being deleted? >>>>> Define "falling off". If the feed is paged, does "falling off" mean >>>>> we'll find the entry on the next or previous page? What if the feed >>>>> only shows the 100 most recent items? What should I do with my local >>>>> copy of the entry if suddenly the entry no longer appears in the feed? >>>>> There is a significant difference between falling off and being >>>>> deleted. >>>> >>>> I didn't say there wasn't, I asked it be explained why the difference >>>> matters in this case, to the extent we need a new type and new markup. >>>> >>>> cheers >>>> Bill >>>> >>> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > From owner-atom-syntax@mail.imc.org Wed Jan 02 02:10:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9xkZ-0001qb-G7 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 02:10:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9xkY-0005EZ-PL for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 02:10:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m026vTLn099625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jan 2008 23:57:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m026vTRM099624; Tue, 1 Jan 2008 23:57:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m026vSng099618 for ; Tue, 1 Jan 2008 23:57:28 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=aRlxAbNYs9rf9LcoXQ+2JQAXMm/UlS6uDG+mpU+zzrMaLMXoZ+7Ku qj32wy7mbMvV0O1mBoueQxpebCF5C/9sDl1+ZloT71Ckp/oZQ1PGO XJ+2QG6D2BZNOxNUIMTpdAgSu2XLdGptWhi/5qb31rcL7oQ2v9xML P7/mehV798Ns=; Received: from wb9-a.mail.utexas.edu ([128.83.126.150]) by ironmaiden.mail.utexas.edu with ESMTP; 02 Jan 2008 00:57:28 -0600 Received: (qmail 83503 invoked from network); 2 Jan 2008 06:57:28 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb9.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 2 Jan 2008 06:57:28 -0000 Date: Wed, 2 Jan 2008 00:57:28 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: Mark Nottingham , Bill de hOra , Atom Syntax Subject: Re: Tombstones In-Reply-To: <477B23F3.1010003@gmail.com> Message-ID: References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Also, FWIW, here's an excerpt from the OAI-PMH (protocal for metadata harvesting): http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords (This is a different protocol than the one I mentioned earlier -- OAI-ORE -- and is widely implemented). Perhaps there is some useful wisdom here: 2.5.1 Deleted records If a record is no longer available then it is said to be deleted. Repositories must declare one of three levels of support for deleted records in the deletedRecord element of the Identify response: * no - the repository does not maintain information about deletions. A repository that indicates this level of support must not reveal a deleted status in any response. * persistent - the repository maintains information about deletions with no time limit. A repository that indicates this level of support must persistently keep track of the full history of deletions and consistently reveal the status of a deleted record over time. * transient - the repository does not guarantee that a list of deletions is maintained persistently or consistently. A repository that indicates this level of support may reveal a deleted status for records. If a repository does not keep track of deletions then such records will simply vanish from responses and there will be no way for a harvester to discover deletions through continued incremental harvesting. If a repository does keep track of deletions then the datestamp of the deleted record must be the date and time that it was deleted. Responses to GetRecord request for a deleted record must then include a header with the attribute status="deleted", and must not include metadata or about parts. Similarly, responses to selective harvesting requests with set membership and date range criteria that include deleted records must include the headers of these records. Incremental harvesting will thus discover deletions from repositories that keep track of them. Deleted status is a property of individual records. Like a normal record, a deleted record is identified by a unique identifier, a metadataPrefix and a datestamp. Other records, with different metadataPrefix but the same unique identifier, may remain available for the item. --peter keane From Jeffry.pohl@norasolutions.com Wed Jan 02 03:19:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9yof-00053s-9b for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 03:19:09 -0500 Received: from i03m-62-35-194-164.d4.club-internet.fr ([62.35.194.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9yoe-0004cG-4r for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 03:19:09 -0500 Received: from SY3PPTM17A ([157.159.101.172] helo=SY3PPTM17A) by i03m-62-35-194-164.d4.club-internet.fr ( sendmail 8.13.3/8.13.1) with esmtpa id 1SdslM-000DSZ-yS for atompub-archive@lists.ietf.org; Wed, 2 Jan 2008 09:19:22 +0100 Message-ID: Date: Wed, 2 Jan 2008 09:19:03 +0100 From: "Jeffry pohl" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: vristyne Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Discreet, and effective - gain 3 inches in just 3 months! http://bulcsdnas.com/ From rainadcpl@fraichedecoupe.com Wed Jan 02 06:18:55 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA1cd-0000js-9o for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 06:18:55 -0500 Received: from catv-5665701f.catv.broadband.hu ([86.101.112.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA1cc-0007lL-D7 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 06:18:54 -0500 Received: by 10.148.9.155 with SMTP id XeCJsTfjakoVy; Wed, 2 Jan 2008 12:18:58 +0100 (GMT) Received: by 192.168.45.29 with SMTP id QydldsCdJveLfM.6381046142029; Wed, 2 Jan 2008 12:18:56 +0100 (GMT) Message-ID: <6CFA0F8C.8051CB88@fraichedecoupe.com> Date: Wed, 2 Jan 2008 12:18:53 +0100 From: "olly raina" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: selbayan Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Put on inches where it matters most, on your manhood - peramanantly! http://www.bulcsdnas.com/
From owner-atom-syntax@mail.imc.org Wed Jan 02 15:34:20 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAAI8-00051a-DH for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 15:34:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAAI7-0001J7-Qj for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 15:34:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m02KGFCc056753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 13:16:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m02KGFwi056752; Wed, 2 Jan 2008 13:16:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m02KGDwl056746 for ; Wed, 2 Jan 2008 13:16:14 -0700 (MST) (envelope-from dirk@haun-online.de) Received: (qmail 9490 invoked from network); 2 Jan 2008 20:16:12 -0000 Received: from unknown (HELO [192.168.0.190]) (050981@[84.161.37.18]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 2 Jan 2008 20:16:12 -0000 From: "Dirk Haun" To: "Atom Syntax" Subject: POST for an exisiting id? Date: Wed, 2 Jan 2008 21:09:33 +0100 Message-Id: <20080102200933.1291861785@smtp.haun-online.de> X-Mailer: CTM PowerMail version 5.6.1 build 4499 German (intel) Organization: Terra Software Systems 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 balder-227.proper.com id m02KGFwl056747 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Apologies if I'm missing anything obvious, but I'm just sitting here brooding over an Atom Protocol Exerciser Report and wondering "what does it want from me?" The APE's Mini One / Mini Two test apparently POSTs a second entry for an already existing one (with the same id). Since RFC5023 states that POST is for creation and PUT is for modification, I'm wondering what to do in that situation. We're currently returning a "400 Bad Request" but that doesn't make the APE happy. What should we do instead? Overwrite the old entry? Some other error code? Where in the RFC is that situation covered? Thanks for any hints. bye, Dirk -- http://www.geeklog.net/ From Puljic@andrewsbistro.co.uk Wed Jan 02 17:44:46 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JACKM-0006hC-0T for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 17:44:46 -0500 Received: from 65-166-132-99.goldfieldaccess.net ([65.166.132.99] helo=dial-65-166-135-78.deskmedia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JACKL-0007CX-GB for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 17:44:45 -0500 Received: from ValuedVPRMatrix by andrewsbistro.co.uk with ASMTP id A5B3A71B for ; Wed, 2 Jan 2008 14:45:16 -0800 Received: from ValuedVPRMatrix ([135.148.129.20]) by andrewsbistro.co.uk with ESMTP id 3231086B4251 for ; Wed, 2 Jan 2008 14:45:16 -0800 Message-ID: <7CD6D307.4A2BE56C@andrewsbistro.co.uk> Date: Wed, 2 Jan 2008 14:44:49 -0800 From: "kevney Puljic" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: innesa Content-Type: multipart/alternative; boundary="------------030808050806070703050502" X-Spam-Score: 2.1 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------030808050806070703050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I love my boyfriend's new found size, it fills me up and makes me come twice as quickly. http://Peisogahe.com/ --------------030808050806070703050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I love my boyfriend's new found size, it fills me up and makes me
come twice as quickly. http://Peisogahe.com/
--------------030808050806070703050502-- From owner-atom-syntax@mail.imc.org Wed Jan 02 20:49:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAFDV-0005hc-0C for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 20:49:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAFDS-0006j8-S3 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 20:49:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m031SUHe087727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 18:28:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m031SUo4087726; Wed, 2 Jan 2008 18:28:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m031SSil087719 for ; Wed, 2 Jan 2008 18:28:29 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1051029anc.44 for ; Wed, 02 Jan 2008 17:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=CeoaIUbzo7Qa08Ro+jV+GVcxoOGf63vgGozc1gNbYNo=; b=oYIllCU+9D/TfhG6Ihx/pY+2MYeB0JB5rf5gWvXsjvLJ3fuIJjsr5G/7lxX/2LVPIIMy3C8ZwD80e2oHchxS2v2ULAtJqmW9Ofs2ldoTATNREff6+2PtBJRXhvsz5nDabNO2ywcylEgIwH73NnfDtn/9XJjpYfy4SWSfXvGIvjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=Vs8Gl5OiIpz7OYhhBRAO0S5OCT+RO4QZEP6D2YwmonOj21pDpNFb4RvYPgRcrGwvI6b56euQwP+ikDR7zqomRLixMSWyoq7F3UGgXQOze1jvGs42qVQkYgFR2OmfKlDqSw9Do2X3pUxRtaLF0Qb7RlUc26H8JaKD9OV1DvlZN1Q= Received: by 10.100.216.3 with SMTP id o3mr31613795ang.95.1199323708422; Wed, 02 Jan 2008 17:28:28 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 58sm19434781rnw.4.2008.01.02.17.28.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 17:28:27 -0800 (PST) Message-ID: <477C3A37.2030602@gmail.com> Date: Wed, 02 Jan 2008 17:28:23 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Peter Keane CC: Mark Nottingham , Bill de hOra , Atom Syntax Subject: Re: Tombstones References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Peter Keane wrote: > [snip] > Feed-level elements are of two types: metadata about the feed, and items > in a "set" of things. Throwing a new type in the mix is really a huge > change -- if it's about the feed, OK (but clearly a tombstone is an I disagree. Feeds already contain several sets of things... entries, authors, contributors, links, and categories. Adding a new set of things is not a "huge" change by any stretch of the imagination. > entity of it's own and not metadata about the feed), otherwise you are > creating a second "set" and there goes the beauty of Atom (and up goes > the cognitive load -- at least at the conceptual level). Perhaps it > comes down to: are tombstones a significant resource (I say yes)? And if Tombstones are not resources. An entry in a trash folder may be a resource, but a tombstone is just a flag that indicates that a particular entry is no longer part of a logical collection. > so, they need to have a URI. Also, a new type seems to create a tighter > coupling with the client than is ideal -- why must I (the client or > client implementor) need to think about a new type? I'd much prefer an > atom:category element that flagged an entry as "deleted" with an > expectation that it'd hang around for some period of time (soft-delete) > and at some indeterminate point fall off the feed (hard-deleted) if/when > the feed publisher so chooses. It just seems more natural to deal with > a deleted entry like that -- a new type seems to me to presuppose an > understanding of the possible use cases which is simply impossible at > this point. > The key challenge with these kinds of views is that there are existing applications and use cases out there that simply do not share this point of view. - James > --peter keane > > On Tue, 1 Jan 2008, James M Snell wrote: > >> >> +1. I've asked several times why using atom:entry would be better than >> x:deleted and I have yet to see a clear, coherent argument. >> >> - James >> >> Mark Nottingham wrote: >>> >>> I still don't understand the pushback that people have against a new >>> feed-level element not "smelling right." Atom explicitly allows >>> extensions there. >>> >>> Cheers, >>> >>> >>> On 02/01/2008, at 1:52 PM, Peter Keane wrote: >>> >>>> >>>> Re: tombstones, I'll just throw in a mention if the OAI-ORE work (Open >>>> Archives Initiative Object Reuse and Exchange - >>>> http://www.openarchives.org/ore/0.1/atom-implementation) which figures >>>> to be very important in archiving/preservation, etc. and serializes a >>>> "Resource Map" (named graphs that represent aggregations of Web >>>> Resources) and serializes them using Atom. >>>> >>>> The issue of tombstones will be big and the previous discussion around >>>> "soft-deletes" (deletions that can be resurrected or perhaps used in >>>> various client-determined ways) will be a significant use case. I >>>> feel like Joe Gregorio's suggestion of two feeds >>>> (http://www.mail-archive.com/atom-syntax@imc.org/msg01092.html) feels >>>> like the best solution for this case. (since those deletes really ARE >>>> of type atom:entry -- a new type does not smell quite right). >>>> >>>> And why can't atom:category be used to indicate that an entry has been >>>> deleted? (In fact, perhaps a few different categories for the >>>> different kinds of "deleted"). >>>> >>>> -peter keane >>>> >>>>> >>>>> James M Snell wrote: >>>>>> Bill de hOra wrote: >>>>>>> [snip] >>>>>>> 1: If it doesn't have a permalink (or a link at all), it's not on >>>>>>> the >>>>>>> web; in all seriousness, why do we care about it? >>>>>> Whether the thing has a permalink or not is irrelevant. We're >>>>>> talking >>>>>> about having a mechanism of indicating when an entry is no longer >>>>>> part >>>>>> of a collection or a feed. It could be that the entry still >>>>>> exists in >>>>>> some form or other somewhere else, but how do I know that the >>>>>> thing is >>>>>> no longer part of a specific feed? >>>>> >>>>> It's not in the feed anymore - but first perhaps define "feed". >>>>> >>>>> >>>>>>> 2: why does it matter, the difference between falling off the >>>>>>> bottom and >>>>>>> being deleted? >>>>>> Define "falling off". If the feed is paged, does "falling off" mean >>>>>> we'll find the entry on the next or previous page? What if the feed >>>>>> only shows the 100 most recent items? What should I do with my local >>>>>> copy of the entry if suddenly the entry no longer appears in the >>>>>> feed? >>>>>> There is a significant difference between falling off and being >>>>>> deleted. >>>>> >>>>> I didn't say there wasn't, I asked it be explained why the difference >>>>> matters in this case, to the extent we need a new type and new markup. >>>>> >>>>> cheers >>>>> Bill >>>>> >>>> >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >> > From owner-atom-syntax@mail.imc.org Wed Jan 02 21:28:26 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAFoo-0006X8-O5 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 21:28:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAFoo-0007Eu-B2 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 21:28:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m032FqJj090575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 19:15:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m032FqOE090574; Wed, 2 Jan 2008 19:15:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m032Fpl9090568 for ; Wed, 2 Jan 2008 19:15:52 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1053784anc.44 for ; Wed, 02 Jan 2008 18:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=xihJGB5rbJIn8mB9D+4vZdIDwnVBlbJz5oxEiLBdv6M=; b=OIFLT5MMP2M8xNgcMk4zm8QPboMqWnijy82EL53UFzjHQ8lSsDMVaiVx2OG1ytTrBoZhlXjUQeGhLZTqkk0nna/DLKvyv6n5laT/eCFYOewILFaIJHKPnd6Dxg/gXcod2kej1l0iTiReo1PXSWNaiYpVgxTF7PlSrgQnRwEkIcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=GvswkC6rpAhVl63KT5GdFr9HOqNlXNjdTojYNaz9rTPdT6NU9qdivyAhTQ84d+hhQ/z7XZcU7auKjytOuDZYrf7KGqccBu/LR6NkxluUhVuREHnkzTBbeIPnLEucudPcBepMD1I9dZ6Jn4kuEHQbM5JJlGz3AGWeX+ZI4qRLqkc= Received: by 10.100.248.9 with SMTP id v9mr31626398anh.77.1199326551030; Wed, 02 Jan 2008 18:15:51 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id s38sm19546411rnb.18.2008.01.02.18.15.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 18:15:50 -0800 (PST) Message-ID: <477C4554.3090407@gmail.com> Date: Wed, 02 Jan 2008 18:15:48 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Updated Tombstones Draft X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Reviving the Tombstones draft. Consider this a work in progress. http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt There are two significant changes: 1. deleted-entry is now part of the Atom namespace 2. a "trash" link relation is registered to point to trash feeds. The trash feed approach and deleted-entry element approaches are definitely compatible with one another. They can be used together or independently. - James From owner-atom-syntax@mail.imc.org Wed Jan 02 21:47:28 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAG7E-0002k9-LQ for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 21:47:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAG7D-0007Rf-VW for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 21:47:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m032YQb7091392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 19:34:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m032YQtT091391; Wed, 2 Jan 2008 19:34:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m032YPVk091385 for ; Wed, 2 Jan 2008 19:34:26 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=qZjYMUDxVBW4UVfrhUIQprw0reQ6fhsjFghTABcMwKrY2qbsScZfs 2UJ/HBn5dUFdTXh9dhj8aUIPi6RA6o3qLhQ4rsDH7FOsPyhj8xmb8 g+u6AOnm4CnO6N2kqWBDReo+eshlAl6pDAG2crfTwREpOqOQ3i1Ky zAfIjfSskNyU=; Received: from wb1-a.mail.utexas.edu ([128.83.126.134]) by ironmaiden.mail.utexas.edu with ESMTP; 02 Jan 2008 20:34:25 -0600 Received: (qmail 61204 invoked from network); 3 Jan 2008 02:34:25 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb1.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 3 Jan 2008 02:34:25 -0000 Date: Wed, 2 Jan 2008 20:34:24 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: Mark Nottingham , Bill de hOra , Atom Syntax Subject: Re: Tombstones In-Reply-To: <477C3A37.2030602@gmail.com> Message-ID: References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On Wed, 2 Jan 2008, James M Snell wrote: > > Peter Keane wrote: >> [snip] >> Feed-level elements are of two types: metadata about the feed, and items >> in a "set" of things. Throwing a new type in the mix is really a huge >> change -- if it's about the feed, OK (but clearly a tombstone is an > > I disagree. Feeds already contain several sets of things... entries, > authors, contributors, links, and categories. Adding a new set of > things is not a "huge" change by any stretch of the imagination. But those are all clearly "metadata about the feed" i.e. they have a well-defined relationship with the feed. Same with entries -- the conceptual model (although not spelled out in the spec) is easy to grok. Being able to abstract out a conceptual model is *really* important and it's what makes Atom so useful. What sort of things are these tombstones? Well, their most obvious relationship is to an entry not the feed itself. How would I extend one of these tombstones in a similar but not-exactly-the-original-purpose way? Atom is an elegant set of *interfaces* and here are these *implementation details* (tombstones) smack dab in the middle. Also, what sort of slippery slope is this? Will this be the start of more bags of stuff being added to a feed? Right now a feed has a 1:1 relationship with it's set of contained items. Suddenly that's 1:2 (entries and tombstones) which effectively means 1:n. Note I still contend that metadata about the feed itself is a different sort of beast. > >> a deleted entry like that -- a new type seems to me to presuppose an >> understanding of the possible use cases which is simply impossible at >> this point. >> > > The key challenge with these kinds of views is that there are existing > applications and use cases out there that simply do not share this point > of view. > I would highly recommend that you take a look at the Open Archives Initiative Protocol for Metadata Harvesting because Atom shows great promise as newer/simpler protocol for the exact same purpose (to the extent that OAI-ORE could replace or at least extend OAI-PMH, it's a done deal since OAI-ORE is expressed in Atom). This is THE widely implemented standard in the archives area and work on issues like tombstones and feed archives with Atom really requires (it seems to me) that folks understand how this is being done right now -- OAI-PMH is a truly impressive piece of work and has proven incredibly useful. --peter From owner-atom-syntax@mail.imc.org Wed Jan 02 22:29:12 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAGlc-0002ok-QF for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 22:29:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAGlb-0007vc-DF for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 22:29:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m033GJBZ093623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 20:16:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m033GJgA093622; Wed, 2 Jan 2008 20:16:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m033GIUH093616 for ; Wed, 2 Jan 2008 20:16:18 -0700 (MST) (envelope-from eb2m-mrt@asahi-net.or.jp) Received: from [192.168.11.10] (r113242.ppp.asahi-net.or.jp [210.167.113.242]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 8A47D512A6 for ; Thu, 3 Jan 2008 12:16:14 +0900 (JST) Date: Thu, 03 Jan 2008 12:16:20 +0900 From: "MURATA Makoto (FAMILY Given)" To: atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: <477C4554.3090407@gmail.com> References: <477C4554.3090407@gmail.com> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.050 Message-Id: <20080103120606.201F.EB2M-MRT@asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > 1. deleted-entry is now part of the Atom namespace I am concerned about this change, since I care about validation of atom feeds containing extensions. It appears that extensions (both standard and proprietrary ones) are being designed without creating full schemas. I fear that lack of schemas eventually hampers evolution of atom. To me, a different namespace for deleted-entry makes much more sense, since the use of NVDL for atom validation becomes more natural. Cheers, -- MURATA Makoto (FAMILY Given) From owner-atom-syntax@mail.imc.org Wed Jan 02 22:49:02 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAH4o-0006GR-NI for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 22:49:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAH4o-00088E-96 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 22:49:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m033VeGX094486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 20:31:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m033Veeo094485; Wed, 2 Jan 2008 20:31:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m033Vdb4094477 for ; Wed, 2 Jan 2008 20:31:40 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1057986anc.44 for ; Wed, 02 Jan 2008 19:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=BKvjY2ZhhHBwZRz9L0d/hx65QO9i9pLAIvKZLCS/tFc=; b=LQnXBuE5cfXkk2e9R0P+ZFSxJ7pbYdjyFEBmUyCnK+467iuJvlvT9MOuQm1Fz9NyNtE1lfkAPKV9agYZxVtFSqhwENtGThliL8tDyyiHUfKh8RCblwdl603Mq7o7Te0ie4Oh4WT5qa3/ojFQ7tMtjA1NHtHWoNC0S2acokyg8+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=duWsbR298zVODX5Hm+wfwEw0O67GDzdxrSnb50Esf9O5TQ9bDgwQ+qh9i3G7ORNb5frH5S/y51IfWXhE27ra/W1x34Xg7VBQxqmhLpqhxJDO08345ptVK2OOWe5uEKagFqlx4YeZMRoEd392GtzED79OO8codGTjCdVcJ0YuCRg= Received: by 10.101.70.5 with SMTP id x5mr10799035ank.35.1199331099297; Wed, 02 Jan 2008 19:31:39 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a44sm19360395rne.12.2008.01.02.19.31.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 19:31:38 -0800 (PST) Message-ID: <477C5718.9080000@gmail.com> Date: Wed, 02 Jan 2008 19:31:36 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "MURATA Makoto (FAMILY Given)" CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <20080103120606.201F.EB2M-MRT@asahi-net.or.jp> In-Reply-To: <20080103120606.201F.EB2M-MRT@asahi-net.or.jp> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Noted. FWIW, I'm happy either way. - James MURATA Makoto (FAMILY Given) wrote: >> 1. deleted-entry is now part of the Atom namespace > > I am concerned about this change, since I care about validation > of atom feeds containing extensions. > > It appears that extensions (both standard and proprietrary ones) > are being designed without creating full schemas. I fear that > lack of schemas eventually hampers evolution of atom. > > To me, a different namespace for deleted-entry makes much more > sense, since the use of NVDL for atom validation becomes more > natural. > > Cheers, > From owner-atom-syntax@mail.imc.org Wed Jan 02 23:26:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAHee-0006yR-3z for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 23:26:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAHed-0000Cn-KZ for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 23:26:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034E0nu003655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:14:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034E0UJ003654; Wed, 2 Jan 2008 21:14:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034Dx39003647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2008 21:14:00 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 0806A23E3AB; Wed, 2 Jan 2008 23:13:57 -0500 (EST) Cc: atom-syntax Message-Id: <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> From: Mark Nottingham To: James M Snell In-Reply-To: <477C4554.3090407@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft Date: Thu, 3 Jan 2008 15:13:55 +1100 References: <477C4554.3090407@gmail.com> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 This looks good, except I'm having trouble with the trash feed; is a client who wishes to implement this spec required to look both for deleted-entry and link/@rel="trash", polling that if present? If so, it seems overly cumbersome to implement two mechanisms. BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> Cheers, On 03/01/2008, at 1:15 PM, James M Snell wrote: > > Reviving the Tombstones draft. Consider this a work in progress. > > http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt > > There are two significant changes: > > 1. deleted-entry is now part of the Atom namespace > 2. a "trash" link relation is registered to point > to trash feeds. > > The trash feed approach and deleted-entry element approaches are > definitely compatible with one another. They can be used together or > independently. > > - James > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jan 02 23:27:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAHfm-0008Ab-EB for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 23:27:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAHfl-0000Df-W7 for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 23:27:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0348L23003178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:08:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0348LwU003177; Wed, 2 Jan 2008 21:08:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0348Jji003167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2008 21:08:20 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9E82223E3AB; Wed, 2 Jan 2008 23:08:18 -0500 (EST) Cc: atom-syntax Message-Id: From: Mark Nottingham To: MURATA Makoto (FAMILY Given) In-Reply-To: <20080103120606.201F.EB2M-MRT@asahi-net.or.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft Date: Thu, 3 Jan 2008 15:08:15 +1100 References: <477C4554.3090407@gmail.com> <20080103120606.201F.EB2M-MRT@asahi-net.or.jp> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On 03/01/2008, at 2:16 PM, MURATA Makoto (FAMILY Given) wrote: > >> 1. deleted-entry is now part of the Atom namespace > > I am concerned about this change, since I care about validation > of atom feeds containing extensions. > > It appears that extensions (both standard and proprietrary ones) > are being designed without creating full schemas. I fear that > lack of schemas eventually hampers evolution of atom. > > To me, a different namespace for deleted-entry makes much more > sense, since the use of NVDL for atom validation becomes more > natural. My .02 -- I think the concern of namespace proliferation outweighs this; schema validation isn't evident on the wire, isn't required for conformance to the spec, and reflects problems in the XML world more than it does issues that will affect developers day-to-day. That having been said, I'm not strongly against using a different namespace; after all, we're using XML... Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jan 02 23:49:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAI1h-0008Gi-0n for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 23:49:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAI1f-0000Vu-Ge for atompub-archive@lists.ietf.org; Wed, 02 Jan 2008 23:49:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034XmmD004503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:33:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034Xmfo004502; Wed, 2 Jan 2008 21:33:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034XlqH004496 for ; Wed, 2 Jan 2008 21:33:47 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 7F569DDC5B for ; Thu, 3 Jan 2008 04:33:46 +0000 (UTC) Message-ID: <477C65AB.9000302@dehora.net> Date: Thu, 03 Jan 2008 04:33:47 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> In-Reply-To: <477C4554.3090407@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 James M Snell wrote: > 1. deleted-entry is now part of the Atom namespace "The Atom namespace is reserved for future forward-compatible revisions of Atom." RFC4287, 6.2. The rfc-editor should have picked this up. > 2. a "trash" link relation is registered to point > to trash feeds. Aside from what we talked about recently, the document only talks about deletion in the past tense; there's no deletion mechanism specified. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 03 00:09:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAIL1-0000TU-PS for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:09:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAIL1-0000hk-Ar for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:09:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034wQqc005604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:58:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034wQ1Y005603; Wed, 2 Jan 2008 21:58:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034wPXB005596 for ; Wed, 2 Jan 2008 21:58:26 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1062677anc.44 for ; Wed, 02 Jan 2008 20:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=rqvmqmhj3CY0DYP7qn799fYyflT8PkymcSVFkGmZOpM=; b=XVMiQm8YArfJwFQUjM1Oi0UxgrCKlbM88roGCiNddD7orT2tntXZ5iGQ/gFCCkm7C64lz28nx+AJU1ugR3iCw5n/rn2cdC7zCVuoX8RLvXzpVkVzQZomWIFtp5rgryP6GGvvWhcbIBnwHB7QnuTDQdvUjm25JtdpEDjkumPkSI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=MMlKv81MO3XhLVAILAy41fDm9BpxhiBGu5hE9xIYu0Gmfk2WKmpSr4FcYsT8h5xBv0yubfKUb+WGEuq/bwJgR9WgORHbG3DZQlqexoVqay5uX6p9O6r9iqVOMiNjZFmV79ay8NO9fTXzPaGmFHQElN1/AY2CxvEThTqGlwllpgo= Received: by 10.101.66.14 with SMTP id t14mr31961414ank.47.1199336305534; Wed, 02 Jan 2008 20:58:25 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a38sm19671369rnc.6.2008.01.02.20.58.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 20:58:25 -0800 (PST) Message-ID: <477C6B6E.80409@gmail.com> Date: Wed, 02 Jan 2008 20:58:22 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> In-Reply-To: <477C65AB.9000302@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Bill de hOra wrote: > > James M Snell wrote: > >> 1. deleted-entry is now part of the Atom namespace > > "The Atom namespace is reserved for future forward-compatible revisions > of Atom." RFC4287, 6.2. > > The rfc-editor should have picked this up. > Picked what up? The rfc-editor is not involved in the publishing of I-D's. If this I-D is published as a Standards Track RFC, it would specifically indicate that it is an update to RFC 4287 and would qualify as a "forward-compatible revision of Atom". I believe that it's up to the Area Director to determine whether or not to allow individual submissions such as this to proceed along that route or whether a WG is required. > >> 2. a "trash" link relation is registered to point >> to trash feeds. > > Aside from what we talked about recently, the document only talks about > deletion in the past tense; there's no deletion mechanism specified. > There's no need to specify a deletion mechanism. A deleted-entry element indicates that an entry has been removed from the feed and the trash link relation points to a resource listing the entries that have been removed. The mechanism used to remove those items is orthogonal to both. - James > cheers > Bill > > From owner-atom-syntax@mail.imc.org Thu Jan 03 00:09:59 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAIL9-0000Ty-C9 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:09:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAIL8-0000hs-QF for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:09:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034qf8q005404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:52:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034qf4o005403; Wed, 2 Jan 2008 21:52:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034qelU005397 for ; Wed, 2 Jan 2008 21:52:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1062409anc.44 for ; Wed, 02 Jan 2008 20:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=/HE+LoLe2s+dAJNS2Cu8NmNblA//jNlRF3xx2GQMCJs=; b=xF5hubrVMpiBS9EcIgVb2UHl2QzB1EeOP3bppqnTvpThM1gm6izgehWHXzxWajF1LtBGQ5N9On9Ox7E1xmw2j42zrJ8f2hp0h4cbt56hj4agSmMeLIQs8Z6Z0NqiCDKTugUsMmiDnYD7CbVUt93d+nl2ZPjfF5DEkMYhMl3UR5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=oLVNGRSWEPfyCkxmZpSrYJ5J5Kk0M0cwCzGdYmN3lOS788zBJY5DfDCnyVkewo/67wxLrWU/RGf4OQqeatPFI5sLFGqBfuAKjz66GhZjb8HIDoow7lecr2Yukme6lyFwoXeiIJo2lSUrfqqMW4JtoTU5r/Z1vQHSa+q0ptrWZLw= Received: by 10.100.206.11 with SMTP id d11mr3201923ang.98.1199335960495; Wed, 02 Jan 2008 20:52:40 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id l31sm12005369hsa.0.2008.01.02.20.52.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 20:52:39 -0800 (PST) Message-ID: <477C6A15.1080902@gmail.com> Date: Wed, 02 Jan 2008 20:52:37 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Mark Nottingham CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> In-Reply-To: <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Mark Nottingham wrote: > This looks good, except I'm having trouble with the trash feed; is a > client who wishes to implement this spec required to look both for > deleted-entry and link/@rel="trash", polling that if present? If so, it > seems overly cumbersome to implement two mechanisms. > The client can look for either. Essentially, the deleted-entry element tells you only that the entry was removed from this particular feed. It does not tell you if the entry exists in some other location. The trash feed is orthogonal to deleted-entry and provides a location where things like soft-deleted items can be collected. For instance, suppose we have an Atompub collection managed by multiple authors, Bob and Joe. Bob deletes an entry. Joe discovers that that the entry has been deleted when he sees the deleted-entry element. If Joe wishes to recover the deleted entry, he can go to the trash feed and look for it there. A client could poll the trash feed to discover deleted items if it wishes to do so, but looking for the deleted-entry items would likely be more efficient. - James > BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> > > Cheers, > > > On 03/01/2008, at 1:15 PM, James M Snell wrote: > >> >> Reviving the Tombstones draft. Consider this a work in progress. >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt >> >> There are two significant changes: >> >> 1. deleted-entry is now part of the Atom namespace >> 2. a "trash" link relation is registered to point >> to trash feeds. >> >> The trash feed approach and deleted-entry element approaches are >> definitely compatible with one another. They can be used together or >> independently. >> >> - James >> > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Thu Jan 03 00:10:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAILb-0000oc-9t for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:10:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAILa-0000iA-NX for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:10:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034vlFo005574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:57:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034vlDu005573; Wed, 2 Jan 2008 21:57:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034vjRg005567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2008 21:57:46 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9EFFC23E49E; Wed, 2 Jan 2008 23:57:43 -0500 (EST) Cc: atom-syntax Message-Id: From: Mark Nottingham To: James M Snell In-Reply-To: <477C6A15.1080902@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft Date: Thu, 3 Jan 2008 15:57:41 +1100 References: <477C4554.3090407@gmail.com> <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> <477C6A15.1080902@gmail.com> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hmm. It seems like you need to say something to this; otherwise people may get the feeling they can use them separately. Cheers, On 03/01/2008, at 3:52 PM, James M Snell wrote: > > Mark Nottingham wrote: >> This looks good, except I'm having trouble with the trash feed; is a >> client who wishes to implement this spec required to look both for >> deleted-entry and link/@rel="trash", polling that if present? If >> so, it >> seems overly cumbersome to implement two mechanisms. >> > > The client can look for either. Essentially, the deleted-entry > element > tells you only that the entry was removed from this particular > feed. It > does not tell you if the entry exists in some other location. The > trash > feed is orthogonal to deleted-entry and provides a location where > things > like soft-deleted items can be collected. For instance, suppose we > have > an Atompub collection managed by multiple authors, Bob and Joe. Bob > deletes an entry. Joe discovers that that the entry has been deleted > when he sees the deleted-entry element. If Joe wishes to recover the > deleted entry, he can go to the trash feed and look for it there. A > client could poll the trash feed to discover deleted items if it > wishes > to do so, but looking for the deleted-entry items would likely be more > efficient. > > - James > >> BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> >> >> Cheers, >> >> >> On 03/01/2008, at 1:15 PM, James M Snell wrote: >> >>> >>> Reviving the Tombstones draft. Consider this a work in progress. >>> >>> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt >>> >>> There are two significant changes: >>> >>> 1. deleted-entry is now part of the Atom namespace >>> 2. a "trash" link relation is registered to point >>> to trash feeds. >>> >>> The trash feed approach and deleted-entry element approaches are >>> definitely compatible with one another. They can be used together >>> or >>> independently. >>> >>> - James >>> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Jan 03 00:11:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAIMO-0000ro-EZ for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:11:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAIMO-0000ia-0Z for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:11:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034wre5005627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:58:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034wrqM005626; Wed, 2 Jan 2008 21:58:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034wqTe005620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2008 21:58:52 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2A57C23E458; Wed, 2 Jan 2008 23:58:50 -0500 (EST) Cc: atom-syntax Message-Id: <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> From: Mark Nottingham To: Bill de hOra In-Reply-To: <477C65AB.9000302@dehora.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft Date: Thu, 3 Jan 2008 15:58:48 +1100 References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 03/01/2008, at 3:33 PM, Bill de hOra wrote: >> >> 1. deleted-entry is now part of the Atom namespace > > "The Atom namespace is reserved for future forward-compatible > revisions of Atom." RFC4287, 6.2. ... which begs the question: does this qualify as such? Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Jan 03 00:12:33 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAINc-0001VT-W9 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:12:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAINa-0000jJ-KM for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 00:12:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034xXEM005658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 21:59:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m034xXmp005657; Wed, 2 Jan 2008 21:59:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m034xWIB005650 for ; Wed, 2 Jan 2008 21:59:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1062718anc.44 for ; Wed, 02 Jan 2008 20:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=OpwUpF7d7/PQLksPODRmlaMsV1m3srwGsX1PTZF9yno=; b=lo5bAdYSTpfXjvp2FQ6geD+Rij/zpzrqJQGR5BFcKFaZHAPsxkIAQTbZAcdmxkTcY5WmwmyNUpoX2zemG5FOR9rz5KGjn5iivkmrJxXCzpmtyRi0gm0Lm24zgew7upGp4QeRYkhJ42yzjdm7Llr1/Dkm5FDwAsEHuC8G8oVr7Wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=HpxJ7ZnjsRPo1pe65mi9JUWyYNlxk0QRo/R7PqvDXaFWt1TDtVysKERb2hydPFRcUVRcb9XLCRdwKSkXFb8xv9/5hV+sli/4EKyuyrZPuFvGX01A/MlplKqvHKw73fHU5gIxU8yfQ/8oEUOg89LEhKH/fGj2gyd3dFy5sXx4qFQ= Received: by 10.101.66.14 with SMTP id t14mr31963227ank.47.1199336372338; Wed, 02 Jan 2008 20:59:32 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a68sm19519600rnc.13.2008.01.02.20.59.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 20:59:31 -0800 (PST) Message-ID: <477C6BB0.4010704@gmail.com> Date: Wed, 02 Jan 2008 20:59:28 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Mark Nottingham CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> <477C6A15.1080902@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 +1. I was already thinking that some text was needed describing the relationship between these. - James Mark Nottingham wrote: > Hmm. It seems like you need to say something to this; otherwise people > may get the feeling they can use them separately. > > Cheers, > > > On 03/01/2008, at 3:52 PM, James M Snell wrote: > >> >> Mark Nottingham wrote: >>> This looks good, except I'm having trouble with the trash feed; is a >>> client who wishes to implement this spec required to look both for >>> deleted-entry and link/@rel="trash", polling that if present? If so, it >>> seems overly cumbersome to implement two mechanisms. >>> >> >> The client can look for either. Essentially, the deleted-entry element >> tells you only that the entry was removed from this particular feed. It >> does not tell you if the entry exists in some other location. The trash >> feed is orthogonal to deleted-entry and provides a location where things >> like soft-deleted items can be collected. For instance, suppose we have >> an Atompub collection managed by multiple authors, Bob and Joe. Bob >> deletes an entry. Joe discovers that that the entry has been deleted >> when he sees the deleted-entry element. If Joe wishes to recover the >> deleted entry, he can go to the trash feed and look for it there. A >> client could poll the trash feed to discover deleted items if it wishes >> to do so, but looking for the deleted-entry items would likely be more >> efficient. >> >> - James >> >>> BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> >>> >>> Cheers, >>> >>> >>> On 03/01/2008, at 1:15 PM, James M Snell wrote: >>> >>>> >>>> Reviving the Tombstones draft. Consider this a work in progress. >>>> >>>> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt >>>> >>>> >>>> There are two significant changes: >>>> >>>> 1. deleted-entry is now part of the Atom namespace >>>> 2. a "trash" link relation is registered to point >>>> to trash feeds. >>>> >>>> The trash feed approach and deleted-entry element approaches are >>>> definitely compatible with one another. They can be used together or >>>> independently. >>>> >>>> - James >>>> >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Thu Jan 03 01:26:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAJXb-00089G-AR for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 01:26:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAJXa-0001Qn-ES for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 01:26:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m036Dg2M009863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 23:13:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m036Dgc9009862; Wed, 2 Jan 2008 23:13:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m036Dft3009856 for ; Wed, 2 Jan 2008 23:13:41 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=RMWI0DuJjzC0mF/4PmqZyHmZW31H6azCXzcNIVAAK5f3tWp9qc9N4 2zG9SFlKRI3YIsKcEkzprgDb4haO2YHF/RFadIWjUsij83sKaKKrp 83kjPnkzG/sQiywR4BSLdROYJxGvSGLGSebd1izeyD+HwNitKlJld veJUqnINxVGs=; Received: from wb8-a.mail.utexas.edu ([128.83.126.148]) by ironman.mail.utexas.edu with ESMTP; 03 Jan 2008 00:13:40 -0600 Received: (qmail 91004 invoked from network); 3 Jan 2008 06:13:40 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb8.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 3 Jan 2008 06:13:40 -0000 Date: Thu, 3 Jan 2008 00:13:40 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: Mark Nottingham , atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: <477C6BB0.4010704@gmail.com> Message-ID: References: <477C4554.3090407@gmail.com> <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> <477C6A15.1080902@gmail.com> <477C6BB0.4010704@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 The trash feed is primarily for recovering a soft-deleted item correct? The OS analogy is a bit strained since the OS "trash" is the means by which you get rid of stuff and only secondarily provides a means to retrieve things. Something like "removed" or "archived" or some such might be more descriptive. This "trash/removed/archived" feed is optional, correct? I.e., it'll be used by server implementations optimized for soft-deletes (and wouldn't likely be used for comment spam, for instance)? Also, since deleted-entry has an atom:id I can happily keep thinking of it as a kind of entry (quacks like a duck... ;-)), so I'll rescind my previous compliants. All-in-all this looks like it covers the cases described in OAI-PMH (which from my POV is a very good thing). thanks! peter keane On Wed, 2 Jan 2008, James M Snell wrote: > > +1. I was already thinking that some text was needed describing the > relationship between these. > > - James > > Mark Nottingham wrote: >> Hmm. It seems like you need to say something to this; otherwise people >> may get the feeling they can use them separately. >> >> Cheers, >> >> >> On 03/01/2008, at 3:52 PM, James M Snell wrote: >> >>> >>> Mark Nottingham wrote: >>>> This looks good, except I'm having trouble with the trash feed; is a >>>> client who wishes to implement this spec required to look both for >>>> deleted-entry and link/@rel="trash", polling that if present? If so, it >>>> seems overly cumbersome to implement two mechanisms. >>>> >>> >>> The client can look for either. Essentially, the deleted-entry element >>> tells you only that the entry was removed from this particular feed. It >>> does not tell you if the entry exists in some other location. The trash >>> feed is orthogonal to deleted-entry and provides a location where things >>> like soft-deleted items can be collected. For instance, suppose we have >>> an Atompub collection managed by multiple authors, Bob and Joe. Bob >>> deletes an entry. Joe discovers that that the entry has been deleted >>> when he sees the deleted-entry element. If Joe wishes to recover the >>> deleted entry, he can go to the trash feed and look for it there. A >>> client could poll the trash feed to discover deleted items if it wishes >>> to do so, but looking for the deleted-entry items would likely be more >>> efficient. >>> >>> - James >>> >>>> BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> >>>> >>>> Cheers, >>>> >>>> >>>> On 03/01/2008, at 1:15 PM, James M Snell wrote: >>>> >>>>> >>>>> Reviving the Tombstones draft. Consider this a work in progress. >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt >>>>> >>>>> >>>>> There are two significant changes: >>>>> >>>>> 1. deleted-entry is now part of the Atom namespace >>>>> 2. a "trash" link relation is registered to point >>>>> to trash feeds. >>>>> >>>>> The trash feed approach and deleted-entry element approaches are >>>>> definitely compatible with one another. They can be used together or >>>>> independently. >>>>> >>>>> - James >>>>> >>>> >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > From owner-atom-syntax@mail.imc.org Thu Jan 03 01:40:06 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAJkM-0004Qi-C9 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 01:40:06 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAJkL-0001aW-Gk for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 01:40:06 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m036PlR0010375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 23:25:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m036PlAH010374; Wed, 2 Jan 2008 23:25:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m036Pk8M010368 for ; Wed, 2 Jan 2008 23:25:46 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1066361anc.44 for ; Wed, 02 Jan 2008 22:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=/uW0jehHjea/lrI+9R3oxs3ifF6B4AAE+B3Bt9L1XoM=; b=o6BXXcCEOnVgZH1tkbqHfE61fnN34B8Pc7mL1v3ul8zfbDrYPdbolfYme3t/lCV4kwncR0wA6571L+r04DFOWQDv2fuXvkXGsrzrKU+BW7Y6hEVw2WbnNUjltB+fFVY8hEVwC4tuTY9pgeXTYpWEOyaKoNLWrRgJ7gWqWCOAoK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=a7gMQ7aXKFfH7vqErfjmelrThMuZ8+9txuWLrexuAUmSrjcLvMPdwVzBGyOLHqu08d2ivYz1ct912jdnE/Oxz+uqTdno0AcqQ4RjGRXqWGQA2CXGUZtn+ObJpIBdvfmpwhA7ItrUlwINmy4nSO1sa9b24/sA3i+el0h97fHN+a4= Received: by 10.100.211.8 with SMTP id j8mr32112968ang.56.1199341545525; Wed, 02 Jan 2008 22:25:45 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 39sm12027361hse.7.2008.01.02.22.25.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jan 2008 22:25:44 -0800 (PST) Message-ID: <477C7FE6.5060401@gmail.com> Date: Wed, 02 Jan 2008 22:25:42 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Peter Keane CC: Mark Nottingham , atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <10B8379E-7866-479B-8423-ACBFA3CD6FB5@mnot.net> <477C6A15.1080902@gmail.com> <477C6BB0.4010704@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Peter Keane wrote: > The trash feed is primarily for recovering a soft-deleted item correct? > The OS analogy is a bit strained since the OS "trash" is the means by > which you get rid of stuff and only secondarily provides a means to > retrieve things. Something like "removed" or "archived" or some such > might be more descriptive. > Yeah, I'll be working on the descriptive test around that a bit. It's not just for soft-delete. The entry could have been permanently removed from the underlying data store and added to a statically generated trash file, primarily for the purpose of keeping it around so it could be recreated later as a new entry. > This "trash/removed/archived" feed is optional, correct? I.e., it'll be > used by server implementations optimized for soft-deletes (and wouldn't > likely be used for comment spam, for instance)? > Right. The trash feed is primarily intended to be used by the server to provide the client a means of recovering deleted entries. For things like comment spam, the trash feed is not going to be needed. > Also, since deleted-entry has an atom:id I can happily keep thinking of > it as a kind of entry (quacks like a duck... ;-)), so I'll rescind my > previous compliants. :-). quacks like a duck with significantly fewer feathers. > > All-in-all this looks like it covers the cases described in OAI-PMH > (which from my POV is a very good thing). > Good to hear. FWIW, after reading through the links you provided, I had come to the same conclusion. - James > thanks! > peter keane > > On Wed, 2 Jan 2008, James M Snell wrote: > >> >> +1. I was already thinking that some text was needed describing the >> relationship between these. >> >> - James >> >> Mark Nottingham wrote: >>> Hmm. It seems like you need to say something to this; otherwise people >>> may get the feeling they can use them separately. >>> >>> Cheers, >>> >>> >>> On 03/01/2008, at 3:52 PM, James M Snell wrote: >>> >>>> >>>> Mark Nottingham wrote: >>>>> This looks good, except I'm having trouble with the trash feed; is a >>>>> client who wishes to implement this spec required to look both for >>>>> deleted-entry and link/@rel="trash", polling that if present? If >>>>> so, it >>>>> seems overly cumbersome to implement two mechanisms. >>>>> >>>> >>>> The client can look for either. Essentially, the deleted-entry element >>>> tells you only that the entry was removed from this particular >>>> feed. It >>>> does not tell you if the entry exists in some other location. The >>>> trash >>>> feed is orthogonal to deleted-entry and provides a location where >>>> things >>>> like soft-deleted items can be collected. For instance, suppose we >>>> have >>>> an Atompub collection managed by multiple authors, Bob and Joe. Bob >>>> deletes an entry. Joe discovers that that the entry has been deleted >>>> when he sees the deleted-entry element. If Joe wishes to recover the >>>> deleted entry, he can go to the trash feed and look for it there. A >>>> client could poll the trash feed to discover deleted items if it wishes >>>> to do so, but looking for the deleted-entry items would likely be more >>>> efficient. >>>> >>>> - James >>>> >>>>> BTW, "trash" is culturally specific; how about "garbage"? <1/2 wink> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> On 03/01/2008, at 1:15 PM, James M Snell wrote: >>>>> >>>>>> >>>>>> Reviving the Tombstones draft. Consider this a work in progress. >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-03.txt >>>>>> >>>>>> >>>>>> >>>>>> There are two significant changes: >>>>>> >>>>>> 1. deleted-entry is now part of the Atom namespace >>>>>> 2. a "trash" link relation is registered to point >>>>>> to trash feeds. >>>>>> >>>>>> The trash feed approach and deleted-entry element approaches are >>>>>> definitely compatible with one another. They can be used together or >>>>>> independently. >>>>>> >>>>>> - James >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >> > From owner-atom-syntax@mail.imc.org Thu Jan 03 03:11:29 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JALAn-0003rX-Jc for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 03:11:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JALAm-0002bV-40 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 03:11:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m037uCiC014967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 00:56:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m037uCIS014966; Thu, 3 Jan 2008 00:56:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m037uAlv014960 for ; Thu, 3 Jan 2008 00:56:11 -0700 (MST) (envelope-from eb2m-mrt@asahi-net.or.jp) Received: from [192.168.11.10] (r113242.ppp.asahi-net.or.jp [210.167.113.242]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 9C5C952D43 for ; Thu, 3 Jan 2008 16:56:10 +0900 (JST) Date: Thu, 03 Jan 2008 16:56:13 +0900 From: "MURATA Makoto (FAMILY Given)" To: atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: References: <20080103120606.201F.EB2M-MRT@asahi-net.or.jp> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.050 Message-Id: <20080103164833.2022.EB2M-MRT@asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 First, if the Tombstone extension is not a must for every atom implementation, it should not use the atom namespace. Second, although I agree that validation is not all mighty, I do believe that it solves some problems. (I will report one interesting example soon.) There is no point in making validation difficult when there are no gains. Cheers, -- MURATA Makoto (FAMILY Given) From owner-atom-syntax@mail.imc.org Thu Jan 03 05:28:23 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JANJG-00045B-V8 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 05:28:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JANJG-0004rU-GV for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 05:28:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03ADpcN024557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 03:13:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03ADpuO024556; Thu, 3 Jan 2008 03:13:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc2-s33.bay0.hotmail.com (bay0-omc2-s33.bay0.hotmail.com [65.54.246.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03ADou1024545 for ; Thu, 3 Jan 2008 03:13:51 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.18]) by bay0-omc2-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jan 2008 02:13:50 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 3 Jan 2008 02:13:50 -0800 Message-ID: Received: from 85.211.236.175 by BAY141-DAV8.phx.gbl with DAV; Thu, 03 Jan 2008 10:13:48 +0000 X-Originating-IP: [85.211.236.175] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <477C4554.3090407@gmail.com> Subject: Re: Updated Tombstones Draft Date: Thu, 3 Jan 2008 10:13:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 03 Jan 2008 10:13:50.0391 (UTC) FILETIME=[55E9EC70:01C84DF1] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d James M Snell wrote: > Reviving the Tombstones draft. Consider this a work in progress. Out of curiostiy, are there any server developers here that are planning (or even just considering) adding tombstone support for something like comment-spam or erasing erroneous posts from a blog? Basically any use-case that might benefit a typical feed reader? Also, for the record, I should express again my preference for using attributes rather than elements for at least the primary fields. If you need justification: 1. It's a more compact representation, which helps counter the arguments of people that think tombstones shouldn't be clogging up a regular feed or should require clients to issue special headers requesting them. 2. It requires less state information to parse (other client developers may disagree, but this makes a significant difference to me). 3. I suspect people are a lot more likely to get your field names wrong when using elements rather than attributes (using "author" instead of "by", "updated" instead of "when"), especially now that you're proposing putting this in the Atom namespace. Then again, if nobody here is planning to use this in a way that would be relevant to me, it doesn't really matter what form it takes. Regards James From owner-atom-syntax@mail.imc.org Thu Jan 03 11:26:54 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JASuE-00011j-NQ for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 11:26:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JASuC-00022M-5H for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 11:26:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03G7Cxf053540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 09:07:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03G7CRP053539; Thu, 3 Jan 2008 09:07:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03G7CGc053532 for ; Thu, 3 Jan 2008 09:07:12 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1098672anc.44 for ; Thu, 03 Jan 2008 08:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=RC4rrdrkJs/8p2IHrVFct0fDuoWnxPNooeBwQjztPG4=; b=B2AUx69+KXaHN9nVwybzTwMPNWJBLCHbrl6maW0pIxIlWgDaZtPEtr/LNeg0T4cmd8dkd5So1ZrHNPjqjJulQbD1p526uXyCaXZLQZZvTH7G5ZDCISJpNIU1YCpgEEagUmsBSXhemPYlRcLyiX/kCU3QXGsHCCb0vGsytYUXb2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=CkVlWPWiPg9WuJZ8LTyXKzIipeo+ChaejZ1nf3NOX/ZpylVHvvCKudetniqcIue8htq0iDz3aqbbOJ6unCfWlb49KdZVSxrPJQyUDLGamurViXMZNwHePxR9JAjuyj8VKWzHZzeZ19DH/LQ/rMALz0rXhw2CATbnXRB51OFT5cs= Received: by 10.100.107.7 with SMTP id f7mr14642875anc.108.1199376431454; Thu, 03 Jan 2008 08:07:11 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 7sm2824809hsx.4.2008.01.03.08.07.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 08:07:10 -0800 (PST) Message-ID: <477D0826.4070802@gmail.com> Date: Thu, 03 Jan 2008 08:07:02 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James Holderness CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 James Holderness wrote: > > James M Snell wrote: >> Reviving the Tombstones draft. Consider this a work in progress. > > Out of curiostiy, are there any server developers here that are planning > (or even just considering) adding tombstone support for something like > comment-spam or erasing erroneous posts from a blog? Basically any > use-case that might benefit a typical feed reader? > I will be implementing support for it in an upcoming version of IBM's internal blogs and will likely add support to, at the very least, the Lotus Connections blog component -- assuming we get some traction around this approach. > Also, for the record, I should express again my preference for using > attributes rather than elements for at least the primary fields. If you > need justification: > > 1. It's a more compact representation, which helps counter the arguments > of people that think tombstones shouldn't be clogging up a regular feed > or should require clients to issue special headers requesting them. > 2. It requires less state information to parse (other client developers > may disagree, but this makes a significant difference to me). > 3. I suspect people are a lot more likely to get your field names wrong > when using elements rather than attributes (using "author" instead of > "by", "updated" instead of "when"), especially now that you're proposing > putting this in the Atom namespace. > Noted. FWIW, I'm happy with it either way. Works for me. - James > Then again, if nobody here is planning to use this in a way that would > be relevant to me, it doesn't really matter what form it takes. > > Regards > James > > From owner-atom-syntax@mail.imc.org Thu Jan 03 12:19:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATie-0003kG-ML for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 12:19:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JATid-0003JC-9A for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 12:19:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03H1EPl058339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 10:01:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03H1ED6058338; Thu, 3 Jan 2008 10:01:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03H1BXJ058319 for ; Thu, 3 Jan 2008 10:01:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1102881anc.44 for ; Thu, 03 Jan 2008 09:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=f7r0i+HABqyv3AU0TiurT0fqOiS2Z5FRxZBF0WqRbM8=; b=NeSMzpKaUuwbUkfomhk+6EnxVp5o+eIZ3ce+uvE2op5zoLChzaudj/mv4BVpQJRZJRyBvIkHO6L7aUgI0iQYgJM6e24fqV0qRRy+xtIH18ggLIU6uyqcJM567sLzuhFHfSxTrcX2l2Cu/V2LrcVKd9dPBnxxH5UeL/kHyv6ZMTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=v7HyDHSdGnmmwJSbdQ/Ha2EzLieEx9JTHOc0euEXf/cbE4iAi0tLg2NAVHZ+i1PuJLo4/a/GbJm3gwtVPVnwRjmjEjkFbQPUK25sbBYh0WXHHNXSYuteV/GjEF8GMfZJ2AvMy1ZNoWQHkLmv//5T0DD4hIHfhEPjuDkgLWyrZgw= Received: by 10.100.111.5 with SMTP id j5mr31421773anc.100.1199379671260; Thu, 03 Jan 2008 09:01:11 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id c78sm12483377hsa.15.2008.01.03.09.01.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 09:01:10 -0800 (PST) Message-ID: <477D14D4.8020100@gmail.com> Date: Thu, 03 Jan 2008 09:01:08 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: HTTP Working Group , atom-protocol , atom-syntax Subject: Updated Patch X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 I'm cross-posting this to the http and atom mailing lists, my apologies if anyone receives this multiple times. I've posted a fairly minor update to the PATCH I-D. The main change here is that the Allow-Patch header has been changed from a listing of media-ranges to a list of media-types. The reason for the change is that it's really not that likely that a server will specify a range of patch document format types as opposed to providing a specific list of patch formats. The use of the asterisk "*" value is preserved, however, to indicate that the server will accept any patch format. There are a few other minor editorial updates as well. For the most part, I believe this draft is generally complete. All that remains now is seeing if there is any kind of consensus for moving this forward. - James From Alen.Molyneaux@tcffunding.com Thu Jan 03 12:27:39 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATr1-00028r-4G for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 12:27:39 -0500 Received: from [153.104.62.29] (helo=[153.104.62.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JATr0-0004Bv-II for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 12:27:38 -0500 Received: from tol-401-13429 ([107.178.111.84] helo=tol-401-13429) by [153.104.62.29] ( sendmail 8.13.3/8.13.1) with esmtpa id 1lNCNI-000YQX-bf for atompub-archive@lists.ietf.org; Thu, 3 Jan 2008 12:27:49 -0500 Message-ID: <2DC08EBA.83C2446A@tcffunding.com> Date: Thu, 3 Jan 2008 12:27:22 -0500 From: "Alen Molyneaux" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: iusukuyj Content-Type: multipart/alternative; boundary="------------060608040501060101020007" X-Spam-Score: 2.1 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------060608040501060101020007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Don't be the brunt of jokes in the locker room, hang big and proud! http://www.Upsizeseverytin.com/ --------------060608040501060101020007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Don't be the brunt of jokes in the locker room, hang big and proud! http://www.Upsizeseverytin.com/
--------------060608040501060101020007-- From owner-atom-syntax@mail.imc.org Thu Jan 03 12:41:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAU4N-00034z-U3 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 12:41:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAU4N-0003fR-Gr for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 12:41:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03HQXkZ060668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 10:26:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03HQXkw060667; Thu, 3 Jan 2008 10:26:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03HQW8j060650 for ; Thu, 3 Jan 2008 10:26:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1104910anc.44 for ; Thu, 03 Jan 2008 09:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=5Reo+rGQoeEbX5duYCsFgjIt6Fkqbhi6+sd+99A1duI=; b=jnuQYGVkIu+9EE4ZF67t1Ey68S8lv1nXn+uFCpl74eWje7W2XoNEctdX2TeS3SyX+z+fbk71NmtMa/xdXkF+UH66ltb2nTSZsXUiST2p0gNZECTkBftK1Cfnp7uPHpyuDB/1ErjgMjX7W428EeTxeFxFjx2bx2R63vvzxyOt/tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=Ugp9VVzR3qfNxdTHtRv3af8gr6jtroogxeP62Re/pxorg8ocgj/1XIp219Dvnd7Z3hRlAoIZg4S4J1+bvxpUAuhi2MhlQ0FWgO7H+j1wWnVp1e/fC0i8xeOtYf+O6lEr++Ud1KcEA6zxEgNh66mdk4WcJ1vUDCl4lHg4ojUo6hI= Received: by 10.100.202.9 with SMTP id z9mr33340777anf.42.1199381189760; Thu, 03 Jan 2008 09:26:29 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id y56sm12498527hsb.1.2008.01.03.09.26.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 09:26:28 -0800 (PST) Message-ID: <477D1AC2.90405@gmail.com> Date: Thu, 03 Jan 2008 09:26:26 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-protocol , atom-syntax Subject: Current features draft feedback X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad The current Atompub Features draft is located at http://tools.ietf.org/html/draft-snell-atompub-feature-12 A number of significant changes were made reflecting the extensive discussions made on the atompub protocol list; however, thus far, I have received very little feedback on those changes. I would very much like to see this move forward and would greatly appreciate it if folks could take a look and let me know what they think. - James From owner-atom-syntax@mail.imc.org Thu Jan 03 13:18:43 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUeR-00018a-DT for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 13:18:43 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAUeP-0004N5-Ti for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 13:18:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03I2JQH063809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 11:02:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03I2Jej063808; Thu, 3 Jan 2008 11:02:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03I2Ivm063801 for ; Thu, 3 Jan 2008 11:02:19 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id C99EBDE199 for ; Thu, 3 Jan 2008 18:02:17 +0000 (UTC) Message-ID: <477D2328.80609@dehora.net> Date: Thu, 03 Jan 2008 18:02:16 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> In-Reply-To: <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Mark Nottingham wrote: > > > On 03/01/2008, at 3:33 PM, Bill de hOra wrote: > >>> >>> 1. deleted-entry is now part of the Atom namespace >> >> "The Atom namespace is reserved for future forward-compatible >> revisions of Atom." RFC4287, 6.2. > > > ... which begs the question: does this qualify as such? Not if the word "revision" means what I think it does. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 03 13:30:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUpe-0003VI-Qg for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 13:30:18 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAUpe-0004Yn-Aa for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 13:30:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03IHRWd065111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 11:17:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03IHRtP065110; Thu, 3 Jan 2008 11:17:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03IHRgj065102 for ; Thu, 3 Jan 2008 11:17:27 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 777A7DCD7A for ; Thu, 3 Jan 2008 18:17:26 +0000 (UTC) Message-ID: <477D26B5.9050201@dehora.net> Date: Thu, 03 Jan 2008 18:17:25 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> In-Reply-To: <477C6B6E.80409@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 James M Snell wrote: > Bill de hOra wrote: >> James M Snell wrote: >> >>> 1. deleted-entry is now part of the Atom namespace >> "The Atom namespace is reserved for future forward-compatible revisions >> of Atom." RFC4287, 6.2. >> >> The rfc-editor should have picked this up. >> > > Picked what up? The rfc-editor is not involved in the publishing of > I-D's. If this I-D is published as a Standards Track RFC, it would > specifically indicate that it is an update to RFC 4287 and would qualify > as a "forward-compatible revision of Atom". I believe that it's up to > the Area Director to determine whether or not to allow individual > submissions such as this to proceed along that route or whether a WG is > required. You seem to be assuming this won't get implemented before it gets to standards track. Until that time, I suggest you revert the namespace. Or make it clear that you intend to use this to create a forward compatible revision of Atom. >>> 2. a "trash" link relation is registered to point >>> to trash feeds. >> Aside from what we talked about recently, the document only talks about >> deletion in the past tense; there's no deletion mechanism specified. >> > > There's no need to specify a deletion mechanism. A deleted-entry > element indicates that an entry has been removed from the feed and the > trash link relation points to a resource listing the entries that have > been removed. The mechanism used to remove those items is orthogonal to > both. Without a mechanism (for delete, sync, undelete, etc), how are we supposed to know whether this metadata is useful or well-designed outside whatever private application originally needed it? Or how it interacts with Atompub operations, or some other protocol? Or what happens when there are multiple trash feeds? Or further extended metadata? Or where 95% of comments are spam? Or how it interacts with DELETE/POST? Or whether it can be used for dead letter queuing? In other posts you've suggested you need something just like this, so let me suggest if you have a mechanism or a technical reason, at least document it as an example. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 03 13:48:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAV6q-0005bk-7L for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 13:48:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAV6p-0004rU-Lt for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 13:48:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03ITuGg065964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 11:29:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03ITu7g065963; Thu, 3 Jan 2008 11:29:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03ITsP3065956 for ; Thu, 3 Jan 2008 11:29:56 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4034799rvf.34 for ; Thu, 03 Jan 2008 10:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=UGrqoaR5XmK6ZWLSALBh2qGlFaoRcPhxdw/nlD8pjYg=; b=V4k2rJFGp4eT/woizYq+D1DpbvPipgQ/MZPbzoZFruPJOfuX/SKSP+xKsYdNLzlbOh2wLgS5eD1KV1Q9mxoefsYU74Um/BuiiOn+Ct04q5adq1O3YSOfpHcozLnV7/kfOqSKE8bTNiSyFMvCVv8H19kIWt1S6HIlR/Bw1hXX6HU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=rNPhpiKZivbcM9HFOhjKghzNHopQ13bD9T2yrC8K6Vqt46yR1ElpIvFPFzwi6ziy1TEXCIFQUjh5nx/ceGzyEc9EnsYI1RpBcOaVFHhUxhdIVo6XVsk2TzFO3YbJx0AmnvdF5Xa2r21LJm4bsz2hjvMC1Wlf0xK3J4R6kw+9sgE= Received: by 10.141.145.11 with SMTP id x11mr8301523rvn.23.1199384994492; Thu, 03 Jan 2008 10:29:54 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id f42sm1863752rvb.13.2008.01.03.10.29.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 10:29:53 -0800 (PST) Message-ID: <477D2996.40508@gmail.com> Date: Thu, 03 Jan 2008 10:29:42 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax , Lisa Dusseault Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> In-Reply-To: <477D2328.80609@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hmmm... while your opinion is definitely noted, what you personally think it means doesn't really matter in this case. I could be misreading things, but per BCP92, it's actually up to the AD and IESG to decide whether or not it is appropriate for an individual submission to update Atom in this way, especially given that RFC 4287 does not define what a "forwards compatible revision" is or how such revisions are defined. It would likely be good to defer to Lisa's judgement on this point. - James Bill de hOra wrote: > > Mark Nottingham wrote: >> >> >> On 03/01/2008, at 3:33 PM, Bill de hOra wrote: >> >>>> >>>> 1. deleted-entry is now part of the Atom namespace >>> >>> "The Atom namespace is reserved for future forward-compatible >>> revisions of Atom." RFC4287, 6.2. >> >> >> ... which begs the question: does this qualify as such? > > Not if the word "revision" means what I think it does. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Thu Jan 03 14:04:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAVMc-0007sW-3m for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 14:04:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAVMb-0005BM-Ay for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 14:04:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03Ioxet067692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 11:50:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03IoxIj067691; Thu, 3 Jan 2008 11:50:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.240]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03Iow2M067684 for ; Thu, 3 Jan 2008 11:50:58 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by hs-out-2122.google.com with SMTP id 55so4401751hsc.10 for ; Thu, 03 Jan 2008 10:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=IzEw/d08ZiqLYYw27PTVxszfBLG2WwfZuA4ssbF/2Ok=; b=m8K07Jp8fiK4VSgz/vcjPc6WNJVl49H0ffAIvnzNHPZoyd6n7h4MhRQ40iVs3Nrubno1wbaL6xIufY6IdUuCB+GDXeyCL0oHQBIq4tpVaZriX59GelErav7Dccx7HjWklhe9Ftnwmo+B5ZcC2Zfs6lemkhT7H+ioCq6UM/eJL6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=rZqDT8YjNd4bromBziEBw3qH10/MqF+oCxIpXlHqjq6/xHYaPZ8I4uw4O1hnp5s1gW6AmNvETFCnyoLPdoF4LavqYVMvd+eLvyOwrvHUPc8lYYiOvDC9tN0aOKMXvKXKhxbvLIMxoBWueshxWFmRKvGj0yqc9900xKNlOjELCjM= Received: by 10.142.211.10 with SMTP id j10mr4722134wfg.202.1199386256638; Thu, 03 Jan 2008 10:50:56 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id j13sm20546106rne.9.2008.01.03.10.50.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 10:50:55 -0800 (PST) Message-ID: <477D2E8C.1090507@gmail.com> Date: Thu, 03 Jan 2008 10:50:52 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> In-Reply-To: <477D26B5.9050201@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Bill de hOra wrote: > > James M Snell wrote: >> Bill de hOra wrote: >>> James M Snell wrote: >>> >>>> 1. deleted-entry is now part of the Atom namespace >>> "The Atom namespace is reserved for future forward-compatible revisions >>> of Atom." RFC4287, 6.2. >>> >>> The rfc-editor should have picked this up. >>> >> >> Picked what up? The rfc-editor is not involved in the publishing of >> I-D's. If this I-D is published as a Standards Track RFC, it would >> specifically indicate that it is an update to RFC 4287 and would qualify >> as a "forward-compatible revision of Atom". I believe that it's up to >> the Area Director to determine whether or not to allow individual >> submissions such as this to proceed along that route or whether a WG is >> required. > > You seem to be assuming this won't get implemented before it gets to > standards track. Until that time, I suggest you revert the namespace. Or > make it clear that you intend to use this to create a forward compatible > revision of Atom. > Until (and if) it gets to the standards track, the deleted-entry element is no different than any other unknown extension element an application may add to a feed; conformant implementations are required to ignore it and validators will be right to point it out as a validation error. I will update the draft to make it clearer that the intent is to update RFC 4287. > >>>> 2. a "trash" link relation is registered to point >>>> to trash feeds. >>> Aside from what we talked about recently, the document only talks about >>> deletion in the past tense; there's no deletion mechanism specified. >>> >> >> There's no need to specify a deletion mechanism. A deleted-entry >> element indicates that an entry has been removed from the feed and the >> trash link relation points to a resource listing the entries that have >> been removed. The mechanism used to remove those items is orthogonal to >> both. > > Without a mechanism (for delete, sync, undelete, etc), how are we > supposed to know whether this metadata is useful or well-designed > outside whatever private application originally needed it? Or how it > interacts with Atompub operations, or some other protocol? Or what > happens when there are multiple trash feeds? Or further extended > metadata? Or where 95% of comments are spam? Or how it interacts with > DELETE/POST? Or whether it can be used for dead letter queuing? > > In other posts you've suggested you need something just like this, so > let me suggest if you have a mechanism or a technical reason, at least > document it as an example. > I may just be being a bit too obtuse here but I'm really not following this at all. The tombstone is nothing more than a flag that indicates that an entry has been removed from a feed. Why or how it has been removed is inconsequential. The element identifies which entry was removed and optionally specifies who removed it, when it was removed, and provides the ability to specify a comment explaining the deletion. If we're talking about an Atompub collection, whenever an item is deleted, a tombstone may be added to the feed and/or the item may be moved to a trash feed. I'm not sure what else there is to say about it. I cannot imagine a case where a feed will have multiple trash feeds but I cannot rule it out either. For now, it would likely be best to simply leave that bit undefined until it actually becomes an issue. The deleted-entry element is designed to be extensible so if additional metadata is required, it can be easily added. The elements that are there currently represent what my research has indicated to be a lowest common denominator across applications. There could be many ways tombstones are used. For instance, if a paged feed as a high rate of deletions, rather than letting tombstones accumulate ad infinitum, the implementation may decide to only list the most recent deletions in the first ("current") page. Clients that only periodically check the feed may miss a few tombstones now and then but they're also just as likely to have missed the entry that had been deleted. - James > cheers > Bill > > From owner-atom-syntax@mail.imc.org Thu Jan 03 14:52:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAW7W-0001JZ-4F for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 14:52:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAW7V-00064Q-Ey for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 14:52:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03JQstc071030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 12:26:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03JQsXm071029; Thu, 3 Jan 2008 12:26:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03JQrLg071021 for ; Thu, 3 Jan 2008 12:26:53 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=NG4MXOA/zHyPw0zStyjweHYBnkvJLrNDCSWk04ezIpD1bXtq+TYDH NIgsFo5pUiGzAgpetFIrHPj2XAXcm3Fj26hyVQMsB6fjd2JArveAR +yfCqeqiwEEOoMkUTu4PpM5Q+/AN0KiVhAGHnj6cyyK6clgGlVAKo wnIFZcUX1d5g=; Received: from wb2-a.mail.utexas.edu ([128.83.126.136]) by ironman.mail.utexas.edu with SMTP; 03 Jan 2008 13:26:52 -0600 Received: (qmail 50312 invoked from network); 3 Jan 2008 19:26:52 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb2.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 3 Jan 2008 19:26:52 -0000 Date: Thu, 3 Jan 2008 13:26:52 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: Bill de hOra , atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: <477D2E8C.1090507@gmail.com> Message-ID: References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Thu, 3 Jan 2008, James M Snell wrote: > [snip] > I cannot imagine a case where a feed will have multiple trash feeds but > I cannot rule it out either. For now, it would likely be best to simply > leave that bit undefined until it actually becomes an issue. > I suspect there are lots of potential use cases for multiple "trash/removed/storage" feeds in the digital library/archives space, so I think it'd be best to address that issue. (Either prohibit multiple or make them 'type-able'). > There could be many ways tombstones are used. For instance, if a paged > feed as a high rate of deletions, rather than letting tombstones > accumulate ad infinitum, the implementation may decide to only list the > most recent deletions in the first ("current") page. Clients that only Something like a "time-to-live" mechanism for tombstones could be warranted, perhaps. OAI-PMH defines that per "feed" (a repository has a deletion policy), but you could easily do it per tombstone as well. Hmmm -- come to think of it, maybe tombstone ttl policy *should* be defined at the feed level. > periodically check the feed may miss a few tombstones now and then but > they're also just as likely to have missed the entry that had been deleted. > > - James > >> cheers >> Bill >> >> > From owner-atom-syntax@mail.imc.org Thu Jan 03 15:51:26 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAX2E-0008T3-1q for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 15:51:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAX2D-00087S-HJ for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 15:51:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03KZgFv076345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 13:35:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03KZgWd076344; Thu, 3 Jan 2008 13:35:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03KZgWC076337 for ; Thu, 3 Jan 2008 13:35:42 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 4BF95DE199; Thu, 3 Jan 2008 20:35:41 +0000 (UTC) Message-ID: <477D471C.6090106@dehora.net> Date: Thu, 03 Jan 2008 20:35:40 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax CC: Lisa Dusseault Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> In-Reply-To: <477D2E8C.1090507@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 James M Snell wrote: > > Bill de hOra wrote: >> James M Snell wrote: >>> Bill de hOra wrote: >>>> James M Snell wrote: >>>> >>>>> 1. deleted-entry is now part of the Atom namespace >>>> "The Atom namespace is reserved for future forward-compatible revisions >>>> of Atom." RFC4287, 6.2. >>>> >>>> The rfc-editor should have picked this up. >>>> >>> Picked what up? The rfc-editor is not involved in the publishing of >>> I-D's. If this I-D is published as a Standards Track RFC, it would >>> specifically indicate that it is an update to RFC 4287 and would qualify >>> as a "forward-compatible revision of Atom". I believe that it's up to >>> the Area Director to determine whether or not to allow individual >>> submissions such as this to proceed along that route or whether a WG is >>> required. >> You seem to be assuming this won't get implemented before it gets to >> standards track. Until that time, I suggest you revert the namespace. Or >> make it clear that you intend to use this to create a forward compatible >> revision of Atom. >> > > Until (and if) it gets to the standards track, the deleted-entry element > is no different than any other unknown extension element an application > may add to a feed; conformant implementations are required to ignore it > and validators will be right to point it out as a validation error. [cc'd to the AD] I see this as a worst practice, and the rationale above as paper thin. Frankly, I'm unable to conclude this is treating the spec's versioning policy as anything other than a loophole. Please explain why the tombstone markup has been placed in the Atom namespace. As I see it, each third party addition of an arbitrary name into the atom namespace degrades its overall value; Murato makato has given examples as to why. Please recall we were very careful in selecting the set of names for Atom. In this case there are no social or technical gains to be had that I can see. > I will update the draft to make it clearer that the intent is to update > RFC 4287. Then surely the way to do that, is to start work on updating RFC4287 according to an IETF process, not adding arbitrary names via I-Ds and waiting to be called on it here. cheers Bill From owner-atom-syntax@mail.imc.org Thu Jan 03 16:57:28 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAY48-00060w-Ap for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 16:57:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAY46-0000uv-NF for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 16:57:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03LbJTD081636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 14:37:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03LbJe4081635; Thu, 3 Jan 2008 14:37:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03LbIm7081629 for ; Thu, 3 Jan 2008 14:37:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id r21so1694334wxc.28 for ; Thu, 03 Jan 2008 13:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=f1DTlgCVFfewlcSvrH7rTx+WK3Kz54X5hl7LjDFk9Eg=; b=ozrj/0oscxG7AXsAo1knugo4bVtQCZaN1aAAD+bBzDaBvPnls8fd33JDH4apl07x0inFVGbpv2TuNEE4jG+yS/0jD+LtbXZcUQFWmawuzZGF2+Aa0wkUGqC4nwlXSf3FZ73HHwUzqi7bYAIAW/4KKDvhtfoJmsBF81BJh8V+D5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=h8wrSWwn6ZdmV5fgtE0rX9ShMG8BULgPYYjEo9kvwQgy1y+W/E7LdYcCsviQ80t8By0P82588WVt8Ntw9sIX7G+nf4SGwXUagIjiI49Jcbn4jPu3g311rFjRudU3Qo0SIjjG8A5ZxWgYHWC0DIfYNM6FzyJfUYWqYz9Wpw8FH9Q= Received: by 10.151.11.17 with SMTP id o17mr4355380ybi.98.1199396238349; Thu, 03 Jan 2008 13:37:18 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id i51sm20852066rne.0.2008.01.03.13.37.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 13:37:17 -0800 (PST) Message-ID: <477D558B.5040807@gmail.com> Date: Thu, 03 Jan 2008 13:37:15 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax , Lisa Dusseault Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> In-Reply-To: <477D471C.6090106@dehora.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Bill de hOra wrote: > [snip] > > [cc'd to the AD] > > I see this as a worst practice, and the rationale above as paper thin. > Frankly, I'm unable to conclude this is treating the spec's versioning > policy as anything other than a loophole. > > Please explain why the tombstone markup has been placed in the Atom The reasons are simple: 1. This is a generic capability that is applicable to a broad range of application cases. That is, it is not application or implementation specific. 2. Implementors are already starting to face issues with supporting a broad and growing number of extension namespaces. Now whether these are good enough reasons, I'll leave that for Lisa to decide. FWIW, I'm fine with it either way. I made this change based on feedback from others here on this list. > namespace. As I see it, each third party addition of an arbitrary name > into the atom namespace degrades its overall value; Murato makato has > given examples as to why. Please recall we were very careful in > selecting the set of names for Atom. In this case there are no social or > technical gains to be had that I can see. > >> I will update the draft to make it clearer that the intent is to update >> RFC 4287. > > Then surely the way to do that, is to start work on updating RFC4287 > according to an IETF process, not adding arbitrary names via I-Ds and > waiting to be called on it here. > There is a reason I am bringing this to this forum for discussion rather than just writing up some code and deploying it. The process of review for Individual submissions are covered adequately by BCP 92 and I am not interested in just ramming changes to Atom through without adequate review. If it would be better to define tombstones in a separate namespace, then so be it, that's what I'll do; but the decision needs to be made based on general consensus and not on a single, subjective reading of an unclarified restriction in 4287. Lisa: what do you think? - James > cheers > Bill > > From owner-atom-syntax@mail.imc.org Thu Jan 03 17:35:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAYeq-0003pB-44 for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 17:35:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAYep-0001YZ-Ih for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 17:35:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03MAFd8084178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 15:10:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03MAFQL084177; Thu, 3 Jan 2008 15:10:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03MAEhw084170 for ; Thu, 3 Jan 2008 15:10:15 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=ySAg5C90HwK6qxUFHqEOJorJuRpg5c72Zo2HoyGF6F6fq6hSKuOTC SL/lXTRvvUmM+YDgDRIu1UDILPbMgPDGAza47SFA5zIp6HrIrMRTd XOzIvbK1N3I8FPm5VJYTBZA+MecoZ0xFFlUUJZQ6Ul8YEdbqG7OD/ FxYnru7sI+Rw=; Received: from wb1-a.mail.utexas.edu ([128.83.126.134]) by ironmaiden.mail.utexas.edu with ESMTP; 03 Jan 2008 16:10:14 -0600 Received: (qmail 6913 invoked from network); 3 Jan 2008 22:10:14 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb1.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 3 Jan 2008 22:10:14 -0000 Date: Thu, 3 Jan 2008 16:10:14 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: Bill de hOra , atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: <477D558B.5040807@gmail.com> Message-ID: References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> <477D558B.5040807@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Thu, 3 Jan 2008, James M Snell wrote: > > Bill de hOra wrote: >> [snip] >> >> Please explain why the tombstone markup has been placed in the Atom > > The reasons are simple: > > 1. This is a generic capability that is applicable to a broad range of > application cases. That is, it is not application or implementation > specific. > > 2. Implementors are already starting to face issues with supporting a > broad and growing number of extension namespaces. > I don't mean to kick a sleeping dog, but it seems like the ideal way to keep delete capability (agreed that it's broadly applicable) in the Atom namespace is for tombstones to be atom:entry and "marked-for-deletion" to be an atom:category. --peter keane From owner-atom-syntax@mail.imc.org Thu Jan 03 18:39:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAZez-0002GD-Th for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 18:39:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAZez-0002Vq-CO for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 18:39:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03NRctj089391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 16:27:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03NRcrT089390; Thu, 3 Jan 2008 16:27:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03NRZow089371 for ; Thu, 3 Jan 2008 16:27:37 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1130635anc.44 for ; Thu, 03 Jan 2008 15:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=ET93B/NdazBRh03gFad2SIU9fLjOrWo7OSkcSadkG+s=; b=K8Eb/CO8h7LS7KvulfCbj5P5VU4Yy9ECGuvIBthR5zq4WRMp/XWeZ0VP/rcSmF4XYzBirLgMHUeb+CL59gaGXafZ00ULKS5seJ7U4SQpdn0uZfZZoX7hyMHH7OTllGuKATWb43V2MTJjjtiLwd4qKbZ5XhLFlp9Sd6rcBXm5cRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=PSE7kBDmasAnmgRpDGIGh1FwUS+9eM83FQKqaxEG16r4U7AP8hXO7K7nODfQJCqzlQGe3x3s7/Q0NGScOpCaqaAkNgJLvvQFO2mMlUUrHshdUpNg/vIn+IbyxJ+6GR5NT3VWQhEK397Yqqd1+g6dwt1ZG1DYifa0WgvlrqW/nfA= Received: by 10.100.227.20 with SMTP id z20mr26543061ang.106.1199402854574; Thu, 03 Jan 2008 15:27:34 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a44sm20788812rne.12.2008.01.03.15.27.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jan 2008 15:27:34 -0800 (PST) Message-ID: <477D6F63.7090503@gmail.com> Date: Thu, 03 Jan 2008 15:27:31 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-protocol , atom-syntax Subject: Proposal: Atomext WG X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Recent discussions around tombstones, the Atompub Features draft, and other extensions have revealed an apparent need for some level of formal review for I-D's intended for the Standards Track. After discussing the subject with Lisa Dusseault (the Area director), I believe that real progress on these extensions can only be made within the context of a formal IETF WG. Therefore, I am proposing the creation of an "Atom Extensions" (atomext) WG that will be chartered to review and publish Standards Track extensions and revisions to the Atom format and publishing protocol. A draft charter is provided below. - James =========================================== Atom Extensions (atomext) Description of Working Group: The IETF Atom Extensions Working Group shall publish standards-track extensions or compatible revisions to the Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023). This charter explicitly rules out the creation of new versions of the syntax and the protocol, and any changes that are not compatible with either RFC 4287 or RFC 5023. The WG will initially focus on the review of existing proposals for standards track extensions including: * Atom Bidi Extension, draft-snell-atompub-bidi-05 * Atom Tombstones, draft-snell-atompub-tombstones-03 * Atompub Features Extension, draft-snell-atompub-feature-12 Ed Note: shoud fiql be included? draft-nottingham-atompub-fiql-00.txt As proposals for new standards track extensions are published as Internet-Drafts and brought to the attention of the WG, the WG will review the drafts and decide whether or not to take the draft on as a work product of the WG. If a decision is made to pick up the draft, a revision to this charter is required. If the WG runs out of work items, the WG will be closed. The WG will use the same mailing lists used for the original Atom Publishing Format and Protocol working group: atom-syntax@imc.org for discussing the Atom format and atom-protocol@imc.org for discussing the protocol. Thw WG does not intend to hold regular face-to-face meetings, though may do so if deemed necessary or helpful for resolution of specific issues. Goals and Milestones: May 2008 Submit Atom Bidi Extension for consideration as a Proposed Standard May 2008 Submit Atom Tombstones Extension for consideration as a Proposed Standard May 2008 Submit Atompub Features Extension for consideration as a Proposed Standard From owner-atom-syntax@mail.imc.org Thu Jan 03 22:06:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JActb-0004s0-5B for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 22:06:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JActZ-0005iJ-LA for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 22:06:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m042sNs1002896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 19:54:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m042sMxr002895; Thu, 3 Jan 2008 19:54:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m042sKLl002869 for ; Thu, 3 Jan 2008 19:54:21 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [211.26.138.222] (HELO [192.168.0.11]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904452767 for ; Fri, 04 Jan 2008 13:53:48 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Jan 2008 13:53:50 +1100 Subject: Re: Updated Tombstones Draft From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <477D2E8C.1090507@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 4/1/08 5:50 AM, "James M Snell" wrote: > If we're talking about an Atompub collection, whenever an item is > deleted, a tombstone may be added to the feed and/or the item may be > moved to a trash feed. I'm not sure what else there is to say about it. why not a separate feed of tombstones, with each tombstone linking to the respective edit resource? I can see that might be useful: if you don't want to clutter your normal feed with tombstones, and you don't want to reveal the *content* (even just the title/author) of deleted entries (except to those that have appropriate access privileges), but you do want to make available a list of which entries should be deleted. So .. for minimal tombstone elements alone, would they support a child element? e. From owner-atom-syntax@mail.imc.org Thu Jan 03 22:06:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JActe-0004sS-Pq for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 22:06:58 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JActd-0005iN-ET for atompub-archive@lists.ietf.org; Thu, 03 Jan 2008 22:06:58 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m042uPf2003047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 19:56:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m042uPFi003046; Thu, 3 Jan 2008 19:56:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m042uNk0003039 for ; Thu, 3 Jan 2008 19:56:24 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [211.26.138.222] (HELO [192.168.0.11]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904452787 for ; Fri, 04 Jan 2008 13:56:21 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Jan 2008 13:56:23 +1100 Subject: Re: Updated Tombstones Draft 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On 4/1/08 6:26 AM, "Peter Keane" wrote: > I suspect there are lots of potential use cases for multiple > "trash/removed/storage" feeds in the digital library/archives space, so I > think it'd be best to address that issue. (Either prohibit multiple or > make them 'type-able'). speaking of "removed" ... while possible, is it intended that tombstones would be used for the use case of moving an entry *out* of one feed, and placing it into a different feed? (eg. if miscategorised) e. From demuynckugrx@readinganswers.com Fri Jan 04 13:10:22 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqzt-0007gj-7r for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 13:10:22 -0500 Received: from chello084010091146.chello.pl ([84.10.91.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAqzs-00056c-Ry for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 13:10:21 -0500 Received: from maciek ([177.198.199.69]:12514 "EHLO maciek" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by chello084010091146.chello.pl with ESMTP id S22AZQJXOLQSFLIB (ORCPT ); Fri, 4 Jan 2008 19:10:38 +0100 Message-ID: Date: Fri, 4 Jan 2008 19:10:18 +0100 From: "Nicole demuynck" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: sterne Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 080103-0, 2008-01-03), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 When I penetrated her she straightaway knew the difference, 3 inches is a lot! http://wesaglyii.com/ From owner-atom-syntax@mail.imc.org Fri Jan 04 16:40:54 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAuHe-0000T1-Hy for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 16:40:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAuHb-0005O3-W7 for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 16:40:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m04LPIX0074535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 14:25:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m04LPIDm074534; Fri, 4 Jan 2008 14:25:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m04LPHZh074527 for ; Fri, 4 Jan 2008 14:25:17 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id ECC69142274; Fri, 4 Jan 2008 13:25:18 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaAkHWz90is2; Fri, 4 Jan 2008 13:25:12 -0800 (PST) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C2FAD1422D5; Fri, 4 Jan 2008 13:25:10 -0800 (PST) In-Reply-To: <477D471C.6090106@dehora.net> References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-2--16109379 Message-Id: Cc: atom-syntax From: Lisa Dusseault Subject: Re: Updated Tombstones Draft Date: Fri, 4 Jan 2008 13:25:06 -0800 To: Bill de hOra X-Mailer: Apple Mail (2.752.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 --Apple-Mail-2--16109379 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 3, 2008, at 12:35 PM, Bill de hOra wrote: >>>>> >>>>>> 1. deleted-entry is now part of the Atom namespace >>>>> "The Atom namespace is reserved for future forward-compatible >>>>> revisions >>>>> of Atom." RFC4287, 6.2. >>>>> >>>>> The rfc-editor should have picked this up. Since it's just an Internet-Draft, neither IANA nor the RFC Editor have had a chance to review the proposed namespace. I'm not involved officially either because I haven't been asked to sponsor this, nor is it a work item of a WG I advise. >>>>> >>>> Picked what up? The rfc-editor is not involved in the >>>> publishing of >>>> I-D's. If this I-D is published as a Standards Track RFC, it would >>>> specifically indicate that it is an update to RFC 4287 and would >>>> qualify >>>> as a "forward-compatible revision of Atom". I believe that it's >>>> up to >>>> the Area Director to determine whether or not to allow individual >>>> submissions such as this to proceed along that route or whether >>>> a WG is >>>> required. >>> You seem to be assuming this won't get implemented before it gets to >>> standards track. Until that time, I suggest you revert the >>> namespace. Or >>> make it clear that you intend to use this to create a forward >>> compatible >>> revision of Atom. >>> >> Until (and if) it gets to the standards track, the deleted-entry >> element >> is no different than any other unknown extension element an >> application >> may add to a feed; conformant implementations are required to >> ignore it >> and validators will be right to point it out as a validation error. > > [cc'd to the AD] I still read the list, though often a few days behind. My (individual hat on) guess at interpreting the phrase "future forward- compatible revisions" is that the authors preferred to limit the core namespace to core features and not to optional extensions; otherwise there would be text about use by standards-track vs. Informational or Experimental extensions (or even non-IETF extensions). I am not on call here to make a final decision as the document's still a draft. But if it fell to me to decide due to lack of a WG, I'd check the intent with the authors and see if consensus could be gauged on this mailing list. Lack of clear consensus or somebody responsible to gauge consensus (a WG chair) might well stall documents like this one over any open issue. BTW, Informational RFCs extending Atom can get published through the RFC Editor as Independent submissions without IETF review (and the disclaimer indicates these are not IETF documents), again because there's no WG for the independent work to conflict with. Such independent submissions could not update or revise the Atom RFC and thus I'm fairly confident those documents could not use the Atom core namespace. Lisa [.] As an even more pedantic digression, the word "updates", as in "this draft updates RFC4287", has been the cause of Talmudic debate in the IESG and elsewhere. It's used sometimes to indicate that a draft describes an extension to a previous document, even when the extension is completely optional. Other extensions omit the "updates" marker on the logic that if an extension is purely optional, then it doesn't have to be read in order to implement the older spec, and marking the older spec as "udpated by" the newer spec merely adds confusion. I believe there's solid agreement that when a new spec makes changes in the behavior of the older spec, then it has to use either "updates" or "obsoletes". Note that RFC2616 is not updated by RFC2617, while it is updated by RFC2817, and I haven't looked whether there's really solid logic behind that difference in treatement. --Apple-Mail-2--16109379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jan 3, 2008, at = 12:35 PM, Bill de hOra wrote:


=

=A01. = deleted-entry is now part of the Atom namespace

=

"The Atom = namespace is reserved for future forward-compatible revisions

=

of Atom." RFC4287, = 6.2.


The rfc-editor should have picked this = up.


Since it's = just an Internet-Draft, neither IANA nor the RFC Editor have had a = chance to review the proposed namespace.=A0 I'm not involved officially = either because I haven't been asked to sponsor this, nor is it a work = item of a WG I advise.=A0


=

Picked = what up?=A0 The rfc-editor = is not involved in the publishing of

I-D's.=A0 If this I-D is published as a = Standards Track RFC, it would

specifically indicate that it is an update to RFC 4287 and = would qualify

as a "forward-compatible revision of Atom".=A0 I believe that it's up = to

the Area = Director to determine whether or not to allow individual

submissions such as this to = proceed along that route or whether a WG is

required.

You seem to be assuming this = won't get implemented before it gets to

standards track. Until that time, I = suggest you revert the namespace. Or

make it clear that you intend to use = this to create a forward compatible

revision of Atom.


=

Until = (and if) it gets to the standards track, the deleted-entry = element

is no = different than any other unknown extension element an = application

may add to a feed; conformant implementations are required to = ignore it

and = validators will be right to point it out as a validation = error.


[cc'd to the AD]

=

I still read the list, though often a few = days behind.=A0 My (individual hat on) guess at interpreting the phrase = "future forward-compatible revisions" is that the authors preferred to = limit the core namespace to core features and not to optional = extensions; otherwise there would be text about use by standards-track = vs. Informational or Experimental extensions (or even non-IETF = extensions).=A0=A0

I am not on call here to = make a final decision as the document's still a draft.=A0 But if it fell = to me to decide due to lack of a WG, I'd check the intent with the = authors and see if consensus could be gauged on this mailing list.=A0 = Lack of clear consensus or somebody responsible to gauge consensus (a WG = chair) might well stall documents like this one over any open = issue.=A0

BTW, = Informational RFCs extending Atom can get published through the RFC = Editor as Independent submissions without IETF review (and the = disclaimer indicates these are not IETF documents), again because = there's no WG for the independent work to conflict with. = =A0Such=A0independent submissions could not update or revise the Atom = RFC and thus I'm fairly confident those documents could not use the Atom = core namespace.

Lisa

[.] As an even more = pedantic digression, the word "updates", as in "this draft updates = RFC4287", has been the cause of Talmudic debate in the IESG and = elsewhere.=A0 It's used sometimes to indicate that a draft describes an = extension to a previous document, even when the extension is completely = optional.=A0 Other extensions omit the "updates" marker on the logic = that if an extension is purely optional, then it doesn't have to be read = in order to implement the older spec, and marking the older spec as = "udpated by" the newer spec merely adds confusion.=A0 I believe there's = solid agreement that when a new spec makes changes in the behavior of = the older spec, then it has to use either "updates" or "obsoletes".=A0 = =A0Note that RFC2616 is not updated by RFC2617, while it is updated by = RFC2817, and I haven't looked whether there's really solid logic behind = that difference in treatement.


= --Apple-Mail-2--16109379-- From owner-atom-syntax@mail.imc.org Fri Jan 04 20:39:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAy0V-0000X8-Gv for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 20:39:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAy0T-0002TZ-Ue for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 20:39:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m051PoPS086782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 18:25:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m051PoO8086781; Fri, 4 Jan 2008 18:25:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m051PnGT086773 for ; Fri, 4 Jan 2008 18:25:49 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4463295rvf.34 for ; Fri, 04 Jan 2008 17:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=OQil1LhdpCDD3uVNPNXWorfWwcnmzI1eoyzG9GYUIqI=; b=pRtd5NT9v6kIy6JnXKxkZFndReCapbMmV0pNMCzSCkk5GPSpEqwzusk3P17IHJFS0CYL7k7BuUACYhOII3UXCwWjlvT7qR8Hctx/aK7GEdskC3v08SvQJYqpvlYD5Y5ohQTeP5gqVwH2nGk0ZiDgI85IoH5sKkDAvnQL7ZTUhAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=A8n1L1y/Llzjsrx3z20gptrSI7g1fsik/wkfCZqi9aQlTWqAkVOcuQdZ6pGb2KRJ7DJoIHk5ENXgTGsMcRkVQ32tX4RYjOZXrRcQE4mDC/EBRPRbT2tP5X9JWkqX/Kv5UIYOZQ5yLOushuLWR+Qyo90Ocovw74fnUsBBMaz4Wt8= Received: by 10.140.251.1 with SMTP id y1mr6927810rvh.102.1199496348890; Fri, 04 Jan 2008 17:25:48 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id k19sm4861700rvb.18.2008.01.04.17.25.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jan 2008 17:25:48 -0800 (PST) Message-ID: <477EDC91.6020504@gmail.com> Date: Fri, 04 Jan 2008 17:25:37 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Updated Tombstones Draft, Take 2 X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Ok, another rev based on the feedback: http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-04.txt 1. Until we can get the How-to-extend-the-Atom-NS question resolved, I've moved the deleted-entry element back into it's own namespace 2. To address the concerns James Holderness had about using attributes vs. elements, I have moved the two most important pieces of information in the tombstone (the entry id and timestamp) into attributes. For instance, The by and comment are still elements. James comment spam 3. The language in the draft is rather tortured, but I've made a first attempt at more thoroughly explaining the trash link, including a statement that while multiple trash links can be provided, the relationship between them is undefined. As always, comments welcome and requested. - James From owner-atom-syntax@mail.imc.org Fri Jan 04 21:44:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAz19-0005rA-GC for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 21:44:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAz17-0003Q2-67 for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 21:44:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m052QbPf089171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 19:26:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m052Qb4D089170; Fri, 4 Jan 2008 19:26:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m052QaeC089163 for ; Fri, 4 Jan 2008 19:26:37 -0700 (MST) (envelope-from eb2m-mrt@asahi-net.or.jp) Received: from [192.168.11.10] (q063155.ppp.asahi-net.or.jp [203.181.63.155]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 732F938353 for ; Sat, 5 Jan 2008 11:26:35 +0900 (JST) Date: Sat, 05 Jan 2008 11:26:43 +0900 From: "MURATA Makoto (FAMILY Given)" To: "atom-syntax" Subject: Re: Updated Tombstones Draft In-Reply-To: References: <477C4554.3090407@gmail.com> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.050 Message-Id: <20080105112340.9C3D.EB2M-MRT@asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > > Also, for the record, I should express again my preference for using > attributes rather than elements for at least the primary fields. If you need > justification: > > 1. It's a more compact representation, which helps counter the arguments of > people that think tombstones shouldn't be clogging up a regular feed or > should require clients to issue special headers requesting them. > 2. It requires less state information to parse (other client developers may > disagree, but this makes a significant difference to me). > 3. I suspect people are a lot more likely to get your field names wrong when > using elements rather than attributes (using "author" instead of "by", > "updated" instead of "when"), especially now that you're proposing putting > this in the Atom namespace. I would argue that attributes block internationalization (e.g., ruby, gaiji, and bidi), since attribute values cannot contain subordinate elements or attributes. Cheers, -- MURATA Makoto (FAMILY Given) From owner-atom-syntax@mail.imc.org Fri Jan 04 22:14:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAzU1-0006UA-1F for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 22:14:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAzU0-0003kP-HJ for atompub-archive@lists.ietf.org; Fri, 04 Jan 2008 22:14:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0531lxU090213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 20:01:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0531ls2090212; Fri, 4 Jan 2008 20:01:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0531kBI090206 for ; Fri, 4 Jan 2008 20:01:46 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id C0B4BDDF9D for ; Sat, 5 Jan 2008 03:01:45 +0000 (UTC) Message-ID: <477EF318.5010801@dehora.net> Date: Sat, 05 Jan 2008 03:01:44 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> <477D558B.5040807@gmail.com> In-Reply-To: <477D558B.5040807@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d James M Snell wrote: > Bill de hOra wrote: >> [snip] >> >> [cc'd to the AD] >> >> I see this as a worst practice, and the rationale above as paper thin. >> Frankly, I'm unable to conclude this is treating the spec's versioning >> policy as anything other than a loophole. >> >> Please explain why the tombstone markup has been placed in the Atom > > The reasons are simple: > > 1. This is a generic capability that is applicable to a broad range of > application cases. That is, it is not application or implementation > specific. That's quite an assertion; I'll assume you can back it up. > 2. Implementors are already starting to face issues with supporting a > broad and growing number of extension namespaces. What issues are those? Seriously, I'd like to know. cheers Bill From owner-atom-syntax@mail.imc.org Sat Jan 05 00:21:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB1TJ-0006LH-Er for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 00:21:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JB1TH-0005Q1-Tj for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 00:21:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0556gdW095034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2008 22:06:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0556gZh095033; Fri, 4 Jan 2008 22:06:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0556fjU095026 for ; Fri, 4 Jan 2008 22:06:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1235748anc.44 for ; Fri, 04 Jan 2008 21:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=zXt6dFZ79LOViLBIZw76EIuHZYm1AD/LdlToMXxBu3k=; b=cvuRCxASf5y7RY1JW3FVeZEhVZ5raGA63pfLAjqdhyb840bngfi8xfNIzXq1utrqEw15UJ/hfUunyKcdKN6EXeet4Kn7wIWoFi1oeGG69pRt7Ajdomz92te3j0yCJFGdDo0sId2vgJoDYw8wTpaGgQM/Rt2C7jFky/zQNBlmQU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=LkE5QqjXEQpqssKX6ttZQWWM/qbS2ehNatbh84hg7P5VQMGusDUnzTvtCCaaanWRtfpxQJAf8WbQCdhCqphEF4DBFs+yRn6N+Is4Jb5ydcu5xbKef+XkASt7nuWvy4L55JBsNryP4LDCUvjCAXsYZuU4+Aq8cRQ1UOnQ9TXpJco= Received: by 10.100.239.11 with SMTP id m11mr37185806anh.70.1199509601116; Fri, 04 Jan 2008 21:06:41 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a13sm22996525rnc.14.2008.01.04.21.06.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jan 2008 21:06:40 -0800 (PST) Message-ID: <477F105E.4050402@gmail.com> Date: Fri, 04 Jan 2008 21:06:38 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> <477D558B.5040807@gmail.com> <477EF318.5010801@dehora.net> In-Reply-To: <477EF318.5010801@dehora.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I'm not going to bother. For now, I've updated the draft so that deleted-entry is in it's own namespace again and will leave it that way. If/when we can get an Atom Extensions WG going we can revisit the issue of how and when it is appropriate to add new elements/attributes to the Atom namespace. - James Bill de hOra wrote: > > James M Snell wrote: >> Bill de hOra wrote: >>> [snip] >>> >>> [cc'd to the AD] >>> >>> I see this as a worst practice, and the rationale above as paper thin. >>> Frankly, I'm unable to conclude this is treating the spec's versioning >>> policy as anything other than a loophole. >>> >>> Please explain why the tombstone markup has been placed in the Atom >> >> The reasons are simple: >> >> 1. This is a generic capability that is applicable to a broad range of >> application cases. That is, it is not application or implementation >> specific. > > That's quite an assertion; I'll assume you can back it up. > >> 2. Implementors are already starting to face issues with supporting a >> broad and growing number of extension namespaces. > > What issues are those? Seriously, I'd like to know. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Sat Jan 05 02:28:33 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB3SL-0001lD-1D for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 02:28:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JB3SK-0006jy-Km for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 02:28:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m057GpcW001302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 00:16:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m057Gpnm001301; Sat, 5 Jan 2008 00:16:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m057Gn8j001285 for ; Sat, 5 Jan 2008 00:16:50 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904474288 for ; Sat, 05 Jan 2008 18:16:35 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 05 Jan 2008 18:16:38 +1100 Subject: Re: Updated Tombstones Draft, Take 2 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <477EDC91.6020504@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On 5/1/08 12:25 PM, "James M Snell" wrote: > As always, comments welcome and requested. is it intended that tombstones and such could or should be used for the use case of moving an entry out of one feed/collection and into another (eg. correcting a mis-categorisation)? e. From owner-atom-syntax@mail.imc.org Sat Jan 05 02:50:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB3nv-0003kZ-PQ for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 02:50:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JB3nv-000712-Cv for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 02:50:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m057cJug002239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 00:38:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m057cJYO002238; Sat, 5 Jan 2008 00:38:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m057cITT002232 for ; Sat, 5 Jan 2008 00:38:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1242067anc.44 for ; Fri, 04 Jan 2008 23:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=wrFaikl+dfbGxV6EtsP71BPV8AKcfh2pdKwdioY+6GI=; b=JFwrzs5SP9jRuOgRRDuU7I16WMD6ImPyY/FEUTHXPumIZubTXNNIjsaMGsPc75rs1BtvRgiG5ipzscS91vw6Os2RdaUdqM+NEZGwifvs7PPY+9QRaFiMcBa3twzslYUp+U0k8atV6+oQHpwtoc0xUO9Oh+Qi3Y1a7jo2w6Deibo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=MNSIQ/s29LQSDfo58qMIZMW2l+IEJPRxFg86s2pUVcVQlAoP6TEn3KDCl9lx9XW0hZpBI52FcP5q5h95LIQF7mMnW2LfIBpvV0suTOxNP3o3qN90N50eqyyMK4fulLWrP4rSzBcCgtTSmHqBi+mLHAFPpaSLgapmPPL83y9tF9I= Received: by 10.100.152.19 with SMTP id z19mr28453071and.38.1199518698559; Fri, 04 Jan 2008 23:38:18 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id s54sm23483194rnb.8.2008.01.04.23.38.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jan 2008 23:38:18 -0800 (PST) Message-ID: <477F33E3.8090106@gmail.com> Date: Fri, 04 Jan 2008 23:38:11 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Updated Tombstones Draft, Take 2 References: In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 A tombstone communicates nothing more than the fact an entry was removed from the feed. Whether that entry exists in some other form or in some other feed is a separate issue. The tombstone does not provide a way of indicating where the entry may have moved to, only that it's gone. - James Eric Scheid wrote: > On 5/1/08 12:25 PM, "James M Snell" wrote: > >> As always, comments welcome and requested. > > is it intended that tombstones and such could or should be used for the use > case of moving an entry out of one feed/collection and into another (eg. > correcting a mis-categorisation)? > > e. > > From owner-atom-syntax@mail.imc.org Sat Jan 05 07:30:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB8Az-0002kB-NQ for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 07:30:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JB8Ax-0002PU-BU for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 07:30:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05CHv42016367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 05:17:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m05CHvec016366; Sat, 5 Jan 2008 05:17:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05CHu7x016360 for ; Sat, 5 Jan 2008 05:17:56 -0700 (MST) (envelope-from teohuiming.work@gmail.com) Received: by wa-out-1112.google.com with SMTP id l24so11696326waf.22 for ; Sat, 05 Jan 2008 04:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=y0tZzDQwdqDm+IBl3ucc/fLDPfwQVA2YkzvLvdSTSKI=; b=ipuCoE/QuSbtrAZTxX7DKR551/gQJXaYpWZc+nd0QJ7cMOFAXobFwd1/JCNYHfLZq0Z+I0/B7+Xz8nedrEC7ulwSist/gCp0WSKhKU/Vn9XXhcYWnSfxTlQp5WNLSHsGz2mtbKDDaHgpeesSOZ/+8YMJ1RLKiaqDqKHzyC2WcnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JKgtWTwvss9Z3VMrWl1yJ/c7hhC5IfwzcbrL0qD1vGJdPSrBR3Uys63ZMbIDyHFGt25bDNeOlG8Qi6nUHL4w7MVQ6WBUlFg5vKPjNgAX9Tiw7jOdxpNsIaMnaouSs49YrR3miG6iiRqUowzJhWHERsBKGODm5/poGc1/FDIawzg= Received: by 10.114.121.1 with SMTP id t1mr13141649wac.67.1199535475406; Sat, 05 Jan 2008 04:17:55 -0800 (PST) Received: by 10.114.127.14 with HTTP; Sat, 5 Jan 2008 04:17:55 -0800 (PST) Message-ID: <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> Date: Sat, 5 Jan 2008 20:17:55 +0800 From: "Teo Hui Ming" To: "James M Snell" Subject: Re: Updated Tombstones Draft, Take 2 Cc: atom-syntax In-Reply-To: <477EDC91.6020504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477EDC91.6020504@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi James, quoted from draft-snell-atompub-tombstones-04: >Linked "trash" resources are orthogonal to the at:deleted-entry element and are intended to provide servers with a way of allowing clients to recover deleted entries. Is there a consensus on recovery mechanism that can (or should it?) be included in tombstones extension? >For instance, the entries in a feed may be managed by two separate authors, one of whom may delete an entry that the other author wishes to later recover. If a trash feed is provided, the second author can look for a copy of the deleted entry there. In this example, does it imply that a trash feed should contain full representation copy of entries, so that the second author can simply retrieve the copy and POST it back to the original collection feed? -- Teo Hui Ming From owner-atom-syntax@mail.imc.org Sat Jan 05 09:06:38 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JB9fa-0005fF-8m for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 09:06:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JB9fZ-0003HO-OS for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 09:06:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05DrQPB020067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 06:53:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m05DrQHi020066; Sat, 5 Jan 2008 06:53:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s1.bay0.hotmail.com (bay0-omc1-s1.bay0.hotmail.com [65.54.246.73]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05DrQKF020060 for ; Sat, 5 Jan 2008 06:53:26 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.18]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Jan 2008 05:53:25 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 5 Jan 2008 05:53:25 -0800 Message-ID: Received: from 85.211.236.175 by BAY141-DAV8.phx.gbl with DAV; Sat, 05 Jan 2008 13:53:23 +0000 X-Originating-IP: [85.211.236.175] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <477EDC91.6020504@gmail.com> Subject: Re: Updated Tombstones Draft, Take 2 Date: Sat, 5 Jan 2008 13:53:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 05 Jan 2008 13:53:25.0601 (UTC) FILETIME=[57C6ED10:01C84FA2] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad James M Snell wrote: > 2. To address the concerns James Holderness had about using attributes > vs. elements, I have moved the two most important pieces of > information in the tombstone (the entry id and timestamp) into > attributes. Thank you. That is perfect for my needs. I've updated our implementation to match the current draft. Regards James From Parker@4vhc.com Sat Jan 05 11:29:51 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBBuB-00010f-Tf for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 11:29:51 -0500 Received: from host180-41-dynamic.2-79-r.retail.telecomitalia.it ([79.2.41.180]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBBuB-0007lH-6X for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 11:29:51 -0500 Received: by 10.192.100.118 with SMTP id aSQhMiqoSDKuo; Sat, 5 Jan 2008 17:29:56 +0100 (GMT) Received: by 192.168.21.233 with SMTP id SAHBZoiZRdCVeY.1115039098757; Sat, 5 Jan 2008 17:29:54 +0100 (GMT) Message-ID: Date: Sat, 5 Jan 2008 17:29:51 +0100 From: "chanan Parker" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: dichtvou Content-Type: multipart/alternative; boundary="------------010408020400030804020502" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------010408020400030804020502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit After 3 months, I stopped VPXL - 3 inches was more than enough, I was actually afraid of gaining too much! http://howisa.com/ --------------010408020400030804020502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After 3 months, I stopped VPXL - 3 inches was more than enough, I was
actually afraid of gaining too much! http://howisa.com/
--------------010408020400030804020502-- From owner-atom-syntax@mail.imc.org Sat Jan 05 12:47:28 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBD7I-0002Jr-Qb for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 12:47:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBD7H-0005ye-2W for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 12:47:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05HX7g1031368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 10:33:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m05HX7I0031367; Sat, 5 Jan 2008 10:33:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05HX464031360 for ; Sat, 5 Jan 2008 10:33:06 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 894EFDDAC6 for ; Sat, 5 Jan 2008 17:33:03 +0000 (UTC) Message-ID: <477FBF4D.8080003@dehora.net> Date: Sat, 05 Jan 2008 17:33:01 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> <477D558B.5040807@gmail.com> <477EF318.5010801@dehora.net> <477F105E.4050402@gmail.com> In-Reply-To: <477F105E.4050402@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Sorry to hear you're not going to bother; irregardless of my opinion on this particular extension, it could matter a lot, as supporting extension namespaces gets to the heart of how Atom was designed. Particularly I wanted to know if it was physically due to having multiple namespaces*, inconsistency in extension semantics, or both. cheers Bill * for example, I've seen one issue with the XHTML namespace and how firefox renders an Atom document. James M Snell wrote: > I'm not going to bother. For now, I've updated the draft so that > deleted-entry is in it's own namespace again and will leave it that way. > If/when we can get an Atom Extensions WG going we can revisit the issue > of how and when it is appropriate to add new elements/attributes to the > Atom namespace. > > - James > > Bill de hOra wrote: >> >> James M Snell wrote: >>> Bill de hOra wrote: >>>> [snip] >>>> >>>> [cc'd to the AD] >>>> >>>> I see this as a worst practice, and the rationale above as paper thin. >>>> Frankly, I'm unable to conclude this is treating the spec's versioning >>>> policy as anything other than a loophole. >>>> >>>> Please explain why the tombstone markup has been placed in the Atom >>> >>> The reasons are simple: >>> >>> 1. This is a generic capability that is applicable to a broad range of >>> application cases. That is, it is not application or implementation >>> specific. >> >> That's quite an assertion; I'll assume you can back it up. >> >>> 2. Implementors are already starting to face issues with supporting a >>> broad and growing number of extension namespaces. >> >> What issues are those? Seriously, I'd like to know. >> >> cheers >> Bill >> >> From owner-atom-syntax@mail.imc.org Sat Jan 05 13:59:12 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBEEi-0004sC-GU for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 13:59:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBEEh-00071a-TB for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 13:59:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05IkRkK035615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 11:46:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m05IkRhj035614; Sat, 5 Jan 2008 11:46:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05IkQhK035606 for ; Sat, 5 Jan 2008 11:46:27 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4660280rvf.34 for ; Sat, 05 Jan 2008 10:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=mb7fb3jWH1O3SPeh5otlauBKCeqFHJFf3U9InYCKpTI=; b=dp0VrhtoVx8Bl0LX11E59VpB48W9zrgiBSo6ZFzkN4vY3neZvk/SXf2XU3om8qRGZI05GFPbEHXT5nd97NKGZa94ypHOgVPR4SoejTgp7IvR5yUA0YUVylvvyUAUbzhT5BCndAHGbWRLO5yKmWeXhaxSsVRlz6LoMAfsAF23Ckk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=kiwE6Hl8PK2A05l5UqVYaGZs9vb7tNpg8J8UDv0j/4CpVToHTLK3O+WpHiLZ9mh2W+VDx+bpmKAQ+Q44Xsr+C51eKnZ8EIxbgJZ2gmT2F/lElTr+EXrGygYAOAnu/toBjdUveIkoL7+c1+oAmoGDnUKFak2U6UQeD6LBn/t1DK0= Received: by 10.141.22.1 with SMTP id z1mr9633700rvi.282.1199558785467; Sat, 05 Jan 2008 10:46:25 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id b2sm3153868rvf.9.2008.01.05.10.46.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Jan 2008 10:46:24 -0800 (PST) Message-ID: <477FD07F.9060502@gmail.com> Date: Sat, 05 Jan 2008 10:46:23 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <477C6B6E.80409@gmail.com> <477D26B5.9050201@dehora.net> <477D2E8C.1090507@gmail.com> <477D471C.6090106@dehora.net> <477D558B.5040807@gmail.com> <477EF318.5010801@dehora.net> <477F105E.4050402@gmail.com> <477FBF4D.8080003@dehora.net> In-Reply-To: <477FBF4D.8080003@dehora.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Don't get me wrong, I *want* to get these issues resolved, I just don't think we'll have much hope of coming to a reasonable consensus of many of these issues until we can get a WG going. - James Bill de hOra wrote: > > Sorry to hear you're not going to bother; irregardless of my opinion on > this particular extension, it could matter a lot, as supporting > extension namespaces gets to the heart of how Atom was designed. > Particularly I wanted to know if it was physically due to having > multiple namespaces*, inconsistency in extension semantics, or both. > > cheers > Bill > > * for example, I've seen one issue with the XHTML namespace and how > firefox renders an Atom document. > > James M Snell wrote: >> I'm not going to bother. For now, I've updated the draft so that >> deleted-entry is in it's own namespace again and will leave it that >> way. If/when we can get an Atom Extensions WG going we can revisit >> the issue of how and when it is appropriate to add new >> elements/attributes to the Atom namespace. >> >> - James >> >> Bill de hOra wrote: >>> >>> James M Snell wrote: >>>> Bill de hOra wrote: >>>>> [snip] >>>>> >>>>> [cc'd to the AD] >>>>> >>>>> I see this as a worst practice, and the rationale above as paper thin. >>>>> Frankly, I'm unable to conclude this is treating the spec's versioning >>>>> policy as anything other than a loophole. >>>>> >>>>> Please explain why the tombstone markup has been placed in the Atom >>>> >>>> The reasons are simple: >>>> >>>> 1. This is a generic capability that is applicable to a broad range of >>>> application cases. That is, it is not application or implementation >>>> specific. >>> >>> That's quite an assertion; I'll assume you can back it up. >>> >>>> 2. Implementors are already starting to face issues with supporting a >>>> broad and growing number of extension namespaces. >>> >>> What issues are those? Seriously, I'd like to know. >>> >>> cheers >>> Bill >>> >>> > > From owner-atom-syntax@mail.imc.org Sat Jan 05 17:05:26 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBH8w-00025o-Bc for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 17:05:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBH8u-00021t-OF for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 17:05:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05LqS7I044437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 14:52:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m05LqSja044436; Sat, 5 Jan 2008 14:52:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05LqQ5x044429 for ; Sat, 5 Jan 2008 14:52:27 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4701213rvf.34 for ; Sat, 05 Jan 2008 13:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=BNNQXI1GU0xz/k77Hwb6lbHnySJCXOwwR+HIXSvv29Q=; b=JKSsGZKO8Du85zstyfuApg/KFga6We9Hky4rAeZvIayYS0OpvBrxtWFUqYmm+qKW+/BQN7awl5374Lk1EYQ1woVVKCtx8cjoIhEEusvz+HwY0at3/OsyE236huY9oDc9t2uObxLJkXfhztwFuJmqPTb2OAl6T+SDD70AnQ/12nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=OutxWf2kt3sLTXKf3ty+c5BWSjmtt/Ogzh+IlBvK5ww8P4Ln+DMuedV0K601Ji5AUm5d/6jdXA1pXiDWgVj+wiJ6C8T0HCirVqDUphbY31XCNc6dMgtUcN+77T16cH0xyTWa+lwgbbtMkanxpNCj+8PrPQPZNOHxaAkJ11C3KB4= Received: by 10.141.163.12 with SMTP id q12mr9700245rvo.190.1199569944251; Sat, 05 Jan 2008 13:52:24 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id f34sm8787747rvb.3.2008.01.05.13.52.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Jan 2008 13:52:22 -0800 (PST) Message-ID: <477FFC14.2090604@gmail.com> Date: Sat, 05 Jan 2008 13:52:20 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Teo Hui Ming CC: atom-syntax Subject: Re: Updated Tombstones Draft, Take 2 References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> In-Reply-To: <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Teo Hui Ming wrote: > Hi James, > > quoted from draft-snell-atompub-tombstones-04: > >> Linked "trash" resources are orthogonal to the at:deleted-entry > element and are intended to provide servers with a way of allowing > clients to recover deleted entries. > > Is there a consensus on recovery mechanism that can (or should it?) be > included in tombstones extension? > Not currently. Recovery is going to mean different things to different applications. For some, the entry will still be in the database and all that is needed is essentially either a move operation or flipping a bit from deleted to not-deleted. For others, the data will have been removed from the datastore completely and the client needs to completely recreate the entry. For now, I imagine that it would be best to leave the recovery mechanism undefined and let applications get a bit more experience with it before we start nailing down any kind of standard or best practice procedure. >> For instance, the entries in a feed may be managed by two > separate authors, one of whom may delete an entry that > the other author wishes to later recover. If a trash feed > is provided, the second author can look for a copy of the > deleted entry there. > > In this example, does it imply that a trash feed should contain full > representation copy of entries, so that the second author can simply > retrieve the copy and POST it back to the original collection feed? > Quite possibly. I've left this intentionally vague. Suggestions welcome :-) - James From owner-atom-syntax@mail.imc.org Sat Jan 05 18:05:26 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBI50-0007MF-3e for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 18:05:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBI4y-0002ss-OJ for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 18:05:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05MpR9E046847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 15:51:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m05MpR8a046846; Sat, 5 Jan 2008 15:51:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m05MpPQA046840 for ; Sat, 5 Jan 2008 15:51:26 -0700 (MST) (envelope-from eb2m-mrt@asahi-net.or.jp) Received: from [192.168.11.10] (q063140.ppp.asahi-net.or.jp [203.181.63.140]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 36E834D9B9 for ; Sun, 6 Jan 2008 07:51:25 +0900 (JST) Date: Sun, 06 Jan 2008 07:51:35 +0900 From: "MURATA Makoto (FAMILY Given)" To: atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: <477FD07F.9060502@gmail.com> References: <477FBF4D.8080003@dehora.net> <477FD07F.9060502@gmail.com> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.050 Message-Id: <20080106074917.3A15.EB2M-MRT@asahi-net.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 > Don't get me wrong, I *want* to get these issues resolved, I just don't > think we'll have much hope of coming to a reasonable consensus of many > of these issues until we can get a WG going. Then, is the new WG expected to establish guidelines for atom extensions ? I believe that such guidelines would be very useful. Cheers, -- MURATA Makoto (FAMILY Given) From owner-atom-syntax@mail.imc.org Sat Jan 05 19:58:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBJqm-0002ZZ-9V for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 19:58:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBJql-0004ra-TB for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 19:58:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m060lJnC051915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 17:47:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m060lJ43051914; Sat, 5 Jan 2008 17:47:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m060lIQa051908 for ; Sat, 5 Jan 2008 17:47:18 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4736369rvf.34 for ; Sat, 05 Jan 2008 16:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=mCw8WPt4SJata5wuAx8mUhaf/dzliUz3itiV0N9JRyg=; b=IS9vVwisuVTssJdGpzkBseqxkKFheNAEziUo9VJTb9ezbQlLv9sSJ3cIcw18fhh6unI4LNCUgMmQfqKlhkLJWsj51kX1UcsAFil3gmSyHdOVTBAxsiCP/+7DK7dqCL6++SrrXP2BJKKQI3oXwEDN09peLiMAGXBMekkysPVZvDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=VxF/ZZ+nMVb+Kt1pMVEDBOQ35vHfPExSjx9YHYBsgzCLhjKLTANLjhau4UTR9mvWW6lWHzckslcSAic0aBm0pf98RUIxS6LdfEhShwo7z/14NLvU0v0Vek1//iXnSZ5uFkLKerVpfv4PdHivVl06BImLd27Cj7sUKJZuhySAvYM= Received: by 10.140.132.8 with SMTP id f8mr9750863rvd.198.1199580437933; Sat, 05 Jan 2008 16:47:17 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 3sm1710517rvi.14.2008.01.05.16.47.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Jan 2008 16:47:17 -0800 (PST) Message-ID: <47802513.1040009@gmail.com> Date: Sat, 05 Jan 2008 16:47:15 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "MURATA Makoto (FAMILY Given)" CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477FBF4D.8080003@dehora.net> <477FD07F.9060502@gmail.com> <20080106074917.3A15.EB2M-MRT@asahi-net.or.jp> In-Reply-To: <20080106074917.3A15.EB2M-MRT@asahi-net.or.jp> X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Best Practices, perhaps. I'm not so sure about guidelines. At the very least, a new WG will need to clarify exactly how, when and why new elements are added to the Atom NS vs. created in their own namespace. - James MURATA Makoto (FAMILY Given) wrote: >> Don't get me wrong, I *want* to get these issues resolved, I just don't >> think we'll have much hope of coming to a reasonable consensus of many >> of these issues until we can get a WG going. > > Then, is the new WG expected to establish guidelines for atom extensions ? > I believe that such guidelines would be very useful. > > Cheers, From owner-atom-syntax@mail.imc.org Sat Jan 05 21:27:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBLES-0007Cx-NB for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 21:27:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBLES-0005oQ-00 for atompub-archive@lists.ietf.org; Sat, 05 Jan 2008 21:27:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m062F3Gv055625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jan 2008 19:15:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m062F3EP055624; Sat, 5 Jan 2008 19:15:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m062F2lG055617 for ; Sat, 5 Jan 2008 19:15:02 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=wdwmbOSrz6BqwqLFlh+pj7zEB5B8ydT7pW+q4CQxHYOaRAgsLHxXF eazniUy7R0oUh8sHhzo5UvToU5IB0I/DayBNJCR5fHCR7sJq4OLCz n2MAhrnOrGy3mf6PTkQ+BpTE/YZUCgEHLMod3jamD7cDEcuC/QfLw +3c0uIwPxVpM=; Received: from wb2-a.mail.utexas.edu ([128.83.126.136]) by ironmaiden.mail.utexas.edu with SMTP; 05 Jan 2008 20:15:02 -0600 Received: (qmail 18020 invoked from network); 6 Jan 2008 02:15:02 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb2.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 6 Jan 2008 02:15:02 -0000 Date: Sat, 5 Jan 2008 20:15:02 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: "MURATA Makoto (FAMILY Given)" , atom-syntax Subject: Re: Updated Tombstones Draft In-Reply-To: <47802513.1040009@gmail.com> Message-ID: References: <477FBF4D.8080003@dehora.net> <477FD07F.9060502@gmail.com> <20080106074917.3A15.EB2M-MRT@asahi-net.or.jp> <47802513.1040009@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Is there some expectation that the proposed WG would estabish a new "Atom Extensions" namespace? Or simply that extension would get a thumbs up or thumbs down to be in the Atom namespace? --peter keane On Sat, 5 Jan 2008, James M Snell wrote: > > Best Practices, perhaps. I'm not so sure about guidelines. At the very > least, a new WG will need to clarify exactly how, when and why new elements > are added to the Atom NS vs. created in their own namespace. > > - James > > MURATA Makoto (FAMILY Given) wrote: >>> Don't get me wrong, I *want* to get these issues resolved, I just don't >>> think we'll have much hope of coming to a reasonable consensus of many of >>> these issues until we can get a WG going. >> >> Then, is the new WG expected to establish guidelines for atom extensions ? >> I believe that such guidelines would be very useful. >> >> Cheers, > From Lychakrctgc@caterinaguinicelli.com Sun Jan 06 07:04:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBUEj-0004Uk-A2 for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 07:04:17 -0500 Received: from host236-118-dynamic.50-82-r.retail.telecomitalia.it ([82.50.118.236] helo=host31-178-dynamic.54-82-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBUEb-0000uR-Ge for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 07:04:15 -0500 Received: from andream ([165.142.1.34] helo=andream) by host49-116-dynamic.50-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1issKR-000YPX-vk for atompub-archive@lists.ietf.org; Sun, 6 Jan 2008 13:04:41 +0100 Message-ID: <73B01913.6BAB2F38@caterinaguinicelli.com> Date: Sun, 6 Jan 2008 13:04:10 +0100 From: "nihat Lychak" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: er-ready Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 We groped in the club, and when she felt the size of my manhood, it
made her unbelievably horny http://www.siegegunns.com/
From owner-atom-syntax@mail.imc.org Sun Jan 06 10:54:31 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBXpX-00078q-SE for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 10:54:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBXpV-0003Vd-Df for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 10:54:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06FdkUY092106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 08:39:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06FdkHb092105; Sun, 6 Jan 2008 08:39:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with SMTP id m06Fdi9D092092 for ; Sun, 6 Jan 2008 08:39:45 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 06 Jan 2008 15:39:42 -0000 Received: from p508F86F5.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.134.245] by mail.gmx.net (mp002) with SMTP; 06 Jan 2008 16:39:42 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19NejxutclNJk4LAtbw8d7BXw5AmpJl2TYA0rTgU5 4VHOp1FIvtDQGT Message-ID: <4780F639.90608@gmx.de> Date: Sun, 06 Jan 2008 16:39:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: James M Snell CC: HTTP Working Group , atom-protocol , atom-syntax Subject: Re: Updated Patch References: <477D14D4.8020100@gmail.com> In-Reply-To: <477D14D4.8020100@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Hi James, below are some change suggestions and questions: Questions: Section 2., paragraph 6: OLD: It is RECOMMENDED that servers return a 501 (Not Implemented) response if a PATCH request contains any entity-headers the server does not understand. Unexpected or unintended results can occur if a server ignores known or unknown entity headers included in the request. All entity-headers contained in the request apply only to the contained patch document and MUST NOT be applied to the resource being modified. I can't recall why we're making this requirement; it seems to copy a requirement for PUT. However, for PUT, "applying an entity header" just means storing it. What does it mean for PATCH? This introduces a "must-understand" rule without knowing what "understand" precisely means... Section 3.1., paragraph 3: OLD: The Accept-Patch header specifies a comma separated listing of media- types as defined by [RFC2616], Section 3.7. The asterisk character "*" MAY be used to indicate that any patch format is accepted. You may want to state that the ABNF is the one used in RFC2616, not RFC5234. Section 6., paragraph 1: OLD: The security considerations for PATCH are nearly identical to the security considerations for PUT. In addition, one might be concerned that a document that is patched might be more likely to be corrupted, but that concern can be addressed through the use of mechanisms such as conditional requests using ETags and the If-Match request header. I don't think RFC2616 has any specific ones for PUT, so this is a bit misleading... Editorial: - I noticed a broken internal Section link; you may check all them, optimally using xml2rfc to keep track of them. Other than that: Section 1., paragraph 1: OLD: This specification defines the new HTTP 1.1 [RFC2616] method PATCH that is used to apply partial modifications to a resource. NEW: This specification defines the new HTTP/1.1 [RFC2616] method PATCH that is used to apply partial modifications to a resource. Section 2., paragraph 3: OLD: The server MUST apply the entire set of changes atomically and never provide (e.g. in response to a GET during this operation) a partially-modified representation. If the entire patch document cannot be successfully applied then the server MUST fail the entire request, applying none of the changes. The determination of what constitutes a successful PATCH can vary depending on the patch document and the type of resource being modified. The actual method for determining how to apply the patch document to the resource is defined entirely by the origin server. See Error Handling in section 2.2 for details on status codes and possible error conditions. NEW: The server MUST apply the entire set of changes atomically and never provide (e.g. in response to a GET during this operation) a partially-modified representation. If the entire patch document cannot be successfully applied then the server MUST fail the entire request, applying none of the changes. The determination of what constitutes a successful PATCH can vary depending on the patch document and the type of resource being modified. The actual method for determining how to apply the patch document to the resource is defined entirely by the origin server. See Error Handling in Section 2.2 for details on status codes and possible error conditions. (uppercase "Section") Section 2.2., paragraph 2: OLD: Malformed patch document: Can be specified using a 400 Bad Request when the server finds that the patch document provided by the client was not properly formatted. The definition of badly formatted depends on the patch document chosen, but generally if the server finds it cannot handle the patch due to the serialization of the patch document, this response ought to be appropriate. Unsupported patch document: Can be Specified using a 415 Unsupported Media Type when the client sends a patch document format that the server does not support for the resource identified by the Request-URI. Such a response SHOULD include an Accept-Patch response header as described in Section 3.1 to notify the client what patch document formats are supported. Unprocessable request: Can be specified with a 422 Unprocessable Entity [RFC4918] when the server understands the patch document and the syntax of the patch document appears valid, but the server is incapable of processing the request. There are a number of situations that could lead to such a result, for example: * The client attempted to apply a patch document to an empty or non-existent resource, but the patch document chosen cannot be applied to an empty or non-existent resource. * The client attempted to apply a structural modification and the structures assumed to exist did not exist (e.g. a patch which specifies changing element 'foo' to element 'bar' but element 'foo' doesn't exist). * The client attempted to modify a resource in a way that would cause the resource to become invalid. For instance, a modification to a well-formed XML document that would cause it to no longer be well-formed. * The client attempted to modify a resource that has multiple representations but the server was unable to choose which representation to modify. NEW: Malformed patch document: Can be specified using a 400 (Bad Request) status when the server finds that the patch document provided by the client was not properly formatted. The definition of badly formatted depends on the patch document format chosen, but generally if the server finds it cannot handle the patch due to the serialization of the patch document, this response ought to be appropriate. Unsupported patch document: Can be Specified using a 415 (Unsupported Media Type) when the client sends a patch document format that the server does not support for the resource identified by the Request-URI. Such a response SHOULD include an Accept-Patch response header as described in Section 3.1 to notify the client what patch document formats are supported. Unprocessable request: Can be specified with a 422 (Unprocessable Entity) status [RFC4918] when the server understands the patch document and the syntax of the patch document appears valid, but the server is incapable of processing the request. There are a number of situations that could lead to such a result, for example: * The client attempted to apply a patch document to an empty or non-existent resource, but the patch document chosen cannot be applied to an empty or non-existent resource. * The client attempted to apply a structural modification and the structures assumed to exist did not exist (e.g. a patch which specifies changing element 'foo' to element 'bar' but element 'foo' doesn't exist). * The client attempted to modify a resource in a way that would cause the resource to become invalid. For instance, a modification to a well-formed XML document that would cause it to no longer be well-formed. * The client attempted to modify a resource that has multiple representations but the server was unable to choose which representation to modify. (use "NNN (Reason Phrase) status" format throughout) Section 2.2., paragraph 3: OLD: Conflicting modification: Specified with a 412 Precondition Failed when a client uses either the If-Match or If-Unmodified-Since request headers and attempts to apply a patch document to a resource whose state has changed since the patch was created. If the server detects a possible conflicting modification and neither the If-Match or If-Unmodified-Since request headers are used, the server can return a 409 Conflict response. Concurrent modification: When a server receives multiple concurrent requests to modify a resource, those requests SHOULD be queued and processed in the order in which they are received. If a server is incapable of queuing concurrent requests, all subsequent requests SHOULD be rejected with a 409 Conflict until the first modification request is complete. NEW: Conflicting modification: Specified with a 412 (Precondition Failed) status when a client uses either the If-Match or If-Unmodified- Since request headers and attempts to apply a patch document to a resource whose state has changed since the patch was created. If the server detects a possible conflicting modification and neither the If-Match or If-Unmodified-Since request headers are used, the server can return a 409 (Conflict) status response. Concurrent modification: When a server receives multiple concurrent requests to modify a resource, those requests SHOULD be queued and processed in the order in which they are received. If a server is incapable of queuing concurrent requests, all subsequent requests SHOULD be rejected with a 409 (Conflict) status until the first modification request is complete. Section 5.2., paragraph 1: OLD: This specification defines the 209 Content Returned status code (Section 3) to be updated in the registry at . NEW: This specification defines the 209 Content Returned status code (Section 4) to be updated in the registry at . Section 6., paragraph 1: OLD: The security considerations for PATCH are nearly identical to the security considerations for PUT. In addition, one might be concerned that a document that is patched might be more likely to be corrupted, but that concern can be addressed through the use of mechanisms such as conditional requests using ETags and the If-Match request header. NEW: The security considerations for PATCH are nearly identical to the security considerations for PUT . In addition, one might be concerned that a document that is patched might be more likely to be corrupted, but that concern can be addressed through the use of mechanisms such as conditional requests using ETags and the If-Match request header. BR, Julian From owner-atom-syntax@mail.imc.org Sun Jan 06 13:33:20 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBaJE-0003J5-MT for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 13:33:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBaJE-0006qP-8f for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 13:33:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06IFvdI001252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 11:15:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06IFvh1001251; Sun, 6 Jan 2008 11:15:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06IFuPf001243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 11:15:57 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 8B83423E4A9 for ; Sun, 6 Jan 2008 13:15:55 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477EDC91.6020504@gmail.com> Subject: RE: Updated Tombstones Draft, Take 2 Date: Sun, 6 Jan 2008 12:19:42 -0800 Message-ID: <000c01c850a1$7ea63e40$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477EDC91.6020504@gmail.com> Thread-Index: AchPOjJCQV6/1GsQR8uJ+pudDlPcAgBZijLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m06IFvPe001245 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 James M Snell wrote: > 2. To address the concerns James Holderness had about using attributes > vs. elements, I have moved the two most important pieces of > information in the tombstone (the entry id and timestamp) into > attributes. For instance, > > > The by and comment are still elements. I honestly don't understand what was so hard about the element-based encoding. I've implemented a parser for the element-based syntax using SAX--basically the most tedious parsing mechanism there is--and it was not inconvenient in the least. "by", "comment," and "when" are not specific to deletion--they apply to entry creation and entry editing as well. If we can get by without these properties for POST and PUT, then we don't need them for DELETE either. K.I.S.S. In place of "when", atom:updated and/or app:edited should be used. Deleting an entry is definitely a "significant" change (atom:updated) and it is definitely an edit (app:edited). This will also make it easier to see how the tombstones are to be sorted/paged in feeds that are sorted by one of these dates. The draft also needs to specify how the tombstones are interpolated with entries. - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 13:39:10 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBaOs-0006HZ-0u for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 13:39:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBaOr-0006wF-Hd for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 13:39:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06ILT7r001441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 11:21:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06ILTjk001440; Sun, 6 Jan 2008 11:21:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06ILSWk001434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 11:21:29 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id D72C823E4A4 for ; Sun, 6 Jan 2008 13:21:27 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> Subject: RE: Updated Tombstones Draft, Take 2 Date: Sun, 6 Jan 2008 12:25:23 -0800 Message-ID: <000d01c850a2$44b202e0$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477FFC14.2090604@gmail.com> Thread-Index: AchP5Z4ubXUbws/vTM+X9QZQQqoogwAu+i5A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m06ILTWj001435 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 James M Snell wrote: > Teo Hui Ming wrote: > > Hi James, > > > > quoted from draft-snell-atompub-tombstones-04: > > > >> Linked "trash" resources are orthogonal to the at:deleted-entry > > element and are intended to provide servers with a way of allowing > > clients to recover deleted entries. > > > > Is there a consensus on recovery mechanism that can (or > > should it?) be included in tombstones extension? > > > > Not currently. Recovery is going to mean different things to > different applications. For some, the entry will still be in > the database and all that is needed is essentially either a > move operation or flipping a bit from deleted to not-deleted. > For others, the data will have been removed from the > datastore completely and the client needs to completely > recreate the entry. For now, I imagine that it would be best > to leave the recovery mechanism undefined and let > applications get a bit more experience with it before we > start nailing down any kind of standard or best practice procedure. I disagree. If there is no recovery mechanism, then what value does standardizing the "trash" link relation have? As you already pointed out, the trash mechanism is orthonogonal to the tombstone mechanism. It should be specified seperately, along with the recovery mechanism that makes it useful. > > In this example, does it imply that a trash feed should > > contain full representation copy of entries, so that the second author > > can simply retrieve the copy and POST it back to the original > > collection feed? > > Quite possibly. I've left this intentionally vague. > Suggestions welcome :-) It seems to me that WebDAV MOVE would be a better alternative for moving things between a trash collection and a normal collection (both ways). This would let the user choose whether he wants to delete an entry (DELETE) or just move it into the trash (MOVE). - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 13:56:43 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBafq-0003CB-Oh for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 13:56:43 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBafo-0007Nx-Ut for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 13:56:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06IgNdf002411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 11:42:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06IgNLL002410; Sun, 6 Jan 2008 11:42:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06IgMN7002403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 11:42:22 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9817923E4BA for ; Sun, 6 Jan 2008 13:42:21 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D1AC2.90405@gmail.com> Subject: RE: Current features draft feedback Date: Sun, 6 Jan 2008 12:46:17 -0800 Message-ID: <000e01c850a5$2ff83240$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477D1AC2.90405@gmail.com> Thread-Index: AchOLggD21CegrliS9e+qc3kVnYFkACdZUkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m06IgNN6002405 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b James M Snell wrote: > The current Atompub Features draft is located at > > http://tools.ietf.org/html/draft-snell-atompub-feature-12 > > A number of significant changes were made reflecting the > extensive discussions made on the atompub protocol list; > however, thus far, I have received very little feedback on > those changes. I would very much like to see this move > forward and would greatly appreciate it if folks could take a > look and let me know what they think. Once you moved the "must-understand" mechanisms from this feature, this specification became unnecessary, because an application no longer has to differentiate "features" from any other extension elements. Consider: vs: Usually, the namespace declarations are going to be on a higher-level element: vs: The motivation for feature documents was the verbosity of feature descriptions. Using plain old extension elements reduces the verbosity considerably, to the point where feature documents aren't going to be much of a benefit, most of the time. The documentation aspects (f:feature/@href and f:feature/@label), are not useful enough to warrant a whole specification for this. The need for a user-readable label went away with the "must-understand" parts of the specification, because the client no longer has to be able to present the user with a list of features that it doesn't support. You said that @href is intended for programmers, not end users. Programmers should be able to find the documentation for any feature via Google easily, so it seems to not be much of a benefit. - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 14:33:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBbFM-0006ix-GP for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 14:33:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBbFM-00084W-0O for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 14:33:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06JK6xh004775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 12:20:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06JK6Qr004774; Sun, 6 Jan 2008 12:20:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06JK5SP004763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 12:20:06 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 653C423E4BA for ; Sun, 6 Jan 2008 14:20:04 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> Subject: RE: Tombstones Date: Sun, 6 Jan 2008 13:23:54 -0800 Message-ID: <000001c850aa$74b60f10$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AchNsXBg+VrkDp6TQb2Jl6SQIrs66gC9PBGg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Peter Keane wrote: > James Snell wrote: > > I disagree. Feeds already contain several sets of things... > > entries, authors, contributors, links, and categories. Adding a > > new set of things is not a "huge" change by any stretch of > > the imagination. > > But those are all clearly "metadata about the feed" i.e. they > have a well-defined relationship with the feed. Same with > entries -- the conceptual model (although not spelled out in > the spec) is easy to grok. > Being able to abstract out a conceptual model is *really* > important and it's what makes Atom so useful. What sort of > things are these tombstones? > Well, their most obvious relationship is to an entry not the > feed itself. What practical implications does this have? This is just a distinction without a difference. The specification says: Child elements of atom:entry, atom:feed, atom:source, and Person constructs are considered Metadata elements and are described below. Child elements of Person constructs are considered to apply to the construct. The role of other foreign markup is undefined by this specification. There is no "about the feed" there. > How would I extend one of these tombstones in a similar but > not-exactly-the-original-purpose way? Atom is an elegant set of > *interfaces* and here are these *implementation details* > (tombstones) smack dab in the middle. > > Also, what sort of slippery slope is this? Will this be the > start of more bags of stuff being added to a feed? Sure, why not? - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 14:41:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBbNX-0005j9-GZ for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 14:41:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBbNW-0008C5-Vb for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 14:41:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06JPOQc005070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 12:25:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06JPORM005069; Sun, 6 Jan 2008 12:25:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06JPMSE005059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 12:25:23 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C7C3F23E4A9 for ; Sun, 6 Jan 2008 14:25:21 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> Subject: RE: Proposal: Atomext WG Date: Sun, 6 Jan 2008 13:29:17 -0800 Message-ID: <000101c850ab$31d0db20$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477D6F63.7090503@gmail.com> Thread-Index: AchOYHqN7W10DySoS+yc+pV3ecKeRgCRys7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m06JPOSD005063 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 James M Snell wrote: > Recent discussions around tombstones, the Atompub Features > draft, and other extensions have revealed an apparent need > for some level of formal review for I-D's intended for the > Standards Track. After discussing the subject with Lisa > Dusseault (the Area director), I believe that real progress > on these extensions can only be made within the context of a > formal IETF WG. Therefore, I am proposing the creation of an > "Atom Extensions" (atomext) WG that will be chartered to > review and publish Standards Track extensions and revisions > to the Atom format and publishing protocol. A draft charter > is provided below. I think it makes more sense to get people to get some working implementations that have informally agreed on some extensions, and then bring those psuedo-standards to the IETF for standardization. Honestly, though, I'm not really sure what benefit that IETF provides over informal agreement between mailing list members. > The WG will initially focus on the review of existing > proposals for standards track extensions including: > > * Atom Bidi Extension, draft-snell-atompub-bidi-05 How much of a problem is BIDI in Atom today? (This isn't a rhetorical question). Atom documents are almost never hand-entered, and there is already a specification in place for markup up BIDI and even ruby text in general XML. The odds that clients and servers are going to correctly implement this extension--except those targeted direclty towards BIDI users--seem pretty low to me. Personally, it seems much easier to implement the an existing BIDI markup mechanism (Unicode, XML, and/or XHTML) than a new standard. Most Atom constructs that hold human-readable text allow for XHTML, which has its own BIDI mechanism. The main problem seems to be with person constructs, and with extension elements. The Atom BIDI draft doesn't solve the internationalization problems with person constructs because it doesn't provide a way to do Ruby text markup, which is especially important for atom:name. It also doesn't solve the problem with atom:link/@title or other attributes that are language-sensitive. We should have a guideline that says that every extension element that contains human-readable text should be an atom text construct--i.e. that is should support XHTML markup, and the BIDI and Ruby subsets of XHTML in particular. And, the specification for atom:name and other existing language-sensitive elements should be updated so that they meet this guideline. - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 16:09:13 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBck5-00069C-6q for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 16:09:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBck4-00011w-Pq for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 16:09:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06KrAEd009084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 13:53:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06KrArY009083; Sun, 6 Jan 2008 13:53:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Kr7co009075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 13:53:10 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id A4BFB23E4AE for ; Sun, 6 Jan 2008 15:53:06 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com> <002001c8388a$90c65b20$2501a8c0@Junk> <475A288F.10301@gmail.com> <003a01c839ae$bac27ce0$2101a8c0@Junk> <477A5159.2080708@dehora.net> Subject: RE: Feed Paging for Efficient Feed Synchronization Date: Sun, 6 Jan 2008 14:57:01 -0800 Message-ID: <001f01c850b7$739745b0$0701a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <477A5159.2080708@dehora.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchMhPzBSscLSOM+SZ2REbGfa8vq1AEMaGew Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m06KrAcn009078 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Bill de hOra wrote: > Brian Smith wrote: > > I'm pretty sure I agree with you, but please define "stable". > > Look at how twitter implements paging (it's not using atom, > but the concept stands). The content on page=2 of your > twitter changes as a function of new posts on the home page, > although the entries themselves are uniquely identified. > That's not stable. Let's say I have this at time T: Page: (prev) Entry A Entry B Page: (current) Entry C Entry D Page: (next) Entry E Entry F I page through the feed and I am on the second page. Entry E gets updated before I nagivate to the next page page: Page: Entry E Page: (prev) Entry A Entry B Page: (current) Entry C Entry D Page: (next) Entry F Is this still "stable"? Or does stability require snapshot semantics, like this?: Page: Entry E (new version) Page: (prev) Entry A Entry B Page: (current) Entry C Entry D Page: (next) Entry E (old version) Entry F - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 16:46:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBdJv-0007Yc-7q for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 16:46:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBdJs-0001VP-TJ for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 16:46:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06LYEfB011923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 14:34:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06LYEuO011922; Sun, 6 Jan 2008 14:34:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06LYCkf011916 for ; Sun, 6 Jan 2008 14:34:13 -0700 (MST) (envelope-from john@johnpanzer.com) Received: by rv-out-0910.google.com with SMTP id c27so4936280rvf.34 for ; Sun, 06 Jan 2008 13:34:12 -0800 (PST) Received: by 10.141.27.16 with SMTP id e16mr1496921rvj.259.1199655252735; Sun, 06 Jan 2008 13:34:12 -0800 (PST) Received: from ?192.168.1.6? ( [70.231.238.253]) by mx.google.com with ESMTPS id k41sm3330967rvb.24.2008.01.06.13.34.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 13:34:11 -0800 (PST) Message-ID: <47814A12.4010608@acm.org> Date: Sun, 06 Jan 2008 13:37:22 -0800 From: John Panzer Reply-To: jpanzer@acm.org User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: Feed Paging for Efficient Feed Synchronization References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com> <002001c8388a$90c65b20$2501a8c0@Junk> <475A288F.10301@gmail.com> <003a01c839ae$bac27ce0$2101a8c0@Junk> <477A5159.2080708@dehora.net> <001f01c850b7$739745b0$0701a8c0@T60> In-Reply-To: <001f01c850b7$739745b0$0701a8c0@T60> Content-Type: multipart/alternative; boundary="------------010405030607040907000306" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 This is a multi-part message in MIME format. --------------010405030607040907000306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Brian Smith wrote: > Bill de hOra wrote: > >> Brian Smith wrote: >> >>> I'm pretty sure I agree with you, but please define "stable". >>> >> Look at how twitter implements paging (it's not using atom, >> but the concept stands). The content on page=2 of your >> twitter changes as a function of new posts on the home page, >> although the entries themselves are uniquely identified. >> That's not stable. >> > > Let's say I have this at time T: > Page: (prev) > Entry A > Entry B > Page: (current) > Entry C > Entry D > Page: (next) > Entry E > Entry F > > I page through the feed and I am on the second page. Entry E gets updated before I nagivate to the next page page: > > Page: > Entry E > Page: (prev) > Entry A > Entry B > Page: (current) > Entry C > Entry D > Page: (next) > Entry F > > Is this still "stable"? Or does stability require snapshot semantics, like this?: > > Page: > Entry E (new version) > Page: (prev) > Entry A > Entry B > Page: (current) > Entry C > Entry D > Page: (next) > Entry E (old version) > Entry F > > - Brian > > > Call the two concepts page-stability and snapshot-stability (snapshot-stability implies page-stability). Page-stability is a useful concept in itself and doesn't require the overhead of snapshot semantics. I'm most interested in page-stability personally for things like synchronization. --------------010405030607040907000306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m06LYEfB011923 Brian Smith wrote: 
Bill de hOra wrote:
  
Brian Smith wrote:
    
I'm pretty sure I agree with you, but please define =
"stable".
      
Look at how twitter implements paging (it's not using =
atom,=20
but the concept stands). The content on page=3D2 of your=20
twitter changes as a function of new posts on the home page,=20
although the entries themselves are uniquely identified.=20
That's not stable.
    

Let's say I have this at time T:
  Page: (prev)
	Entry A
	Entry B
  Page: (current)
	Entry C
	Entry D
  Page: (next)
	Entry E
	Entry F

I page through the feed and I am on the second page. Entry E gets updated=
 before I nagivate to the next page page:

  Page:
	Entry E
  Page: (prev)
	Entry A
	Entry B
  Page: (current)
	Entry C
	Entry D
  Page: (next)
	Entry F=09

Is this still "stable"? Or does stability require snapshot semantics, lik=
e this?:

  Page:
	Entry E (new version)
  Page: (prev)
      Entry A
	Entry B
  Page: (current)
      Entry C
	Entry D
  Page: (next)
      Entry E (old version)
      Entry F

- Brian
Call the two concepts page-stability and snapshot-stability (snapshot-stability implies page-stability).=C2=A0 Page-stability is a useful concept in itself and doesn't require the overhead of snapshot semantics.=C2=A0 I'm most interested in page-stability personally for thi= ngs like synchronization.



--------------010405030607040907000306-- From owner-atom-syntax@mail.imc.org Sun Jan 06 18:00:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBeTI-00081q-Gs for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:00:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBeTG-0002SE-QM for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:00:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Ml3th015920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 15:47:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06Ml3au015919; Sun, 6 Jan 2008 15:47:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Ml2vg015909 for ; Sun, 6 Jan 2008 15:47:03 -0700 (MST) (envelope-from dave@djpowell.net) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20080106224821.DCRX20647.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Sun, 6 Jan 2008 22:48:21 +0000 Received: from DavePC ([86.4.233.237]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080106224824.GEXL219.aamtaout01-winn.ispmail.ntl.com@DavePC>; Sun, 6 Jan 2008 22:48:24 +0000 From: "David Powell" To: "'Brian Smith'" , "'atom-syntax'" References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> <000001c850aa$74b60f10$0301a8c0@T60> In-Reply-To: <000001c850aa$74b60f10$0301a8c0@T60> Subject: RE: Tombstones Date: Sun, 6 Jan 2008 22:46:56 -0000 Message-ID: <003701c850b6$0fed50a0$2fc7f1e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchNsXBg+VrkDp6TQb2Jl6SQIrs66gC9PBGgAAG/VXA= Content-Language: en-gb Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Brian Smith wrote: > Peter Keane wrote: > > James Snell wrote: > > > I disagree. Feeds already contain several sets of things... > > > entries, authors, contributors, links, and categories. Adding a > > > new set of things is not a "huge" change by any stretch of > > > the imagination. > > > > But those are all clearly "metadata about the feed" i.e. they > > have a well-defined relationship with the feed. Same with > > entries -- the conceptual model (although not spelled out in > > the spec) is easy to grok. > > Being able to abstract out a conceptual model is *really* > > important and it's what makes Atom so useful. What sort of > > things are these tombstones? > > Well, their most obvious relationship is to an entry not the > > feed itself. > > What practical implications does this have? This is just a distinction > without a difference. No. What a metadata element is "about" has no direct implications on implementations, but the implied life-cycle of the metadata and entities involved (entry and feed) do. Say you poll a feed URI twice, you might get back entry 1,2,3 in the first poll, and entry 2,3,4 in the second poll. Stateful Atom implementations will need to store entries that aren't in the most recent polling of the feed URI. This requires entry and feed state to be decoupled. A good example is Microsoft's Feed Platform, which downloads feeds, and presents them to client applications via an API that allows the entries of a feed (including metadata elements) to be accessed as XML structures. If you start putting entry metadata elements at level this simply won't work. Perhaps Windows Feed Platform is faulty for not anticipating James's latest proposal, but I don't think so. > The specification says: > > Child elements of atom:entry, atom:feed, > atom:source, and Person constructs are considered Metadata elements > and are described below. Child elements of Person constructs are > considered to apply to the construct. The role of other foreign > markup is undefined by this specification. > > There is no "about the feed" there. No there isn't, and practically anything is syntactically valid according to the spec. But, I'm not replying to these posts to save people from reading the spec, but to highlight the harmful effects of these extensions. I believe that violating the separation between entry and feed metadata breaks a large and useful category of applications and that approving such behaviour would be extremely damaging to the Atom community. The feed abstraction for Atom and RSS is one of a feed+metadata and a stream of entries+metadata - this has been the case for the last 10 years, and it isn't going to change now. The model is not, as would be required if were to mix entry and feed metadata, a feed+metadata and a stream of entries+metadata + associations with every feed document that that entry has ever been part of just in case there is some sort of misplaced entry metadata hidden at feed level, so that clients looking at an entry can manually reimplement the sliding window mechanism for tombstones or whatever. Urgh. -- Dave From owner-atom-syntax@mail.imc.org Sun Jan 06 18:00:42 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBeTy-0002Tl-NI for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:00:42 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBeTy-0002T2-6B for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:00:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Mkxdn015904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 15:46:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06Mkxao015903; Sun, 6 Jan 2008 15:46:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Mkv83015892 for ; Sun, 6 Jan 2008 15:46:58 -0700 (MST) (envelope-from dave@djpowell.net) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080106224755.RIZQ6201.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Sun, 6 Jan 2008 22:47:55 +0000 Received: from DavePC ([86.4.233.237]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20080106224817.GEWN219.aamtaout01-winn.ispmail.ntl.com@DavePC>; Sun, 6 Jan 2008 22:48:17 +0000 From: "David Powell" To: "'Brian Smith'" , "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> In-Reply-To: <000101c850ab$31d0db20$0301a8c0@T60> Subject: RE: Proposal: Atomext WG Date: Sun, 6 Jan 2008 22:46:56 -0000 Message-ID: <003601c850b6$0c3b6c30$24b24490$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchOYHqN7W10DySoS+yc+pV3ecKeRgCRys7gAAJewiA= Content-Language: en-gb Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m06Mkx83015897 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Brian Smith wrote: >> The WG will initially focus on the review of existing >> proposals for standards track extensions including: >> >> * Atom Bidi Extension, draft-snell-atompub-bidi-05 > > How much of a problem is BIDI in Atom today? (This isn't a rhetorical > question). Atom documents are almost never hand-entered, and there is > already a specification in place for markup up BIDI and even ruby text > in general XML. The odds that clients and servers are going to > correctly implement this extension--except those targeted direclty > towards BIDI users--seem pretty low to me. Personally, it seems much > easier to implement the an existing BIDI markup mechanism (Unicode, > XML, and/or XHTML) than a new standard. I agree. We already have HTML - which supports much more internationalization features than just bidi. We also have Unicode bidi controls, for people who don't want to use HTML for whatever reason. Do we really need 3 different interacting implementations of bidi? This proposal will just cause interop problems when people try to use it with implementations that don't yet support it, when those people could probably have just used the HTML or Unicode techniques with more success. And isn't the purpose of bidi markup usually to clarify ambiguities that would arise from applying the Unicode bidi algorithms? To do that you need to be able to mark up the interior of these text-only elements, which this proposal wouldn't support anyway. As I mentioned in my previous email re: feed/entry metadata elements: Mixing feed and entry metadata is considered harmful (by me). This applies here too, because applying inheritable bidi attributes at level and expecting it to apply to the contained elements is something that can only be done if the implementation of the component that decouples feed elements and entry elements from a stateful feed is aware of it. And we shouldn't be designing extensions that require software to be updated everytime someone writes an Internet Draft in order that they don't corrupt people's data. If we really need support for Ruby and bidi in , and we aren't immediately intending to supercede RFC4287, I think we would be better adding an additional entry/person metadata element that supports HTML names. But to be honest, I'd like to see people knocking on our doors before we start writing drafts to solve potential problems. -- Dave From owner-atom-syntax@mail.imc.org Sun Jan 06 18:27:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBetr-0000a4-Fn for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:27:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBetq-0002l7-UT for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:27:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06NGQBC017684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 16:16:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06NGQQV017683; Sun, 6 Jan 2008 16:16:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06NGPxj017676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 16:16:26 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6E08323E3AB for ; Sun, 6 Jan 2008 18:16:24 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> <000001c850aa$74b60f10$0301a8c0@T60> <003701c850b6$0fed50a0$2fc7f1e0$@net> Subject: RE: Tombstones Date: Sun, 6 Jan 2008 17:20:12 -0800 Message-ID: <000001c850cb$78875f60$0701a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003701c850b6$0fed50a0$2fc7f1e0$@net> Thread-Index: AchNsXBg+VrkDp6TQb2Jl6SQIrs66gC9PBGgAAG/VXAAB1txIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa David Powell wrote: > > What practical implications does this have? This is just a > distinction without a difference. > > If you start putting entry metadata elements at level > this simply won't work. Perhaps Windows Feed Platform is > faulty for not anticipating James's latest proposal, but I > don't think so. If Windows Feed Platform ignores the tombstones it will be working just as James intended. If Windows Feed Platform chokes on the tombstones then it isn't compliant with the atom specification. > No there isn't, and practically anything is syntactically > valid according to the spec. But, I'm not replying to these > posts to save people from reading the spec, but to highlight > the harmful effects of these extensions. I believe that > violating the separation between entry and feed metadata > breaks a large and useful category of applications and that > approving such behaviour would be extremely damaging to the > Atom community. Could you please give an example of such harm. The rationale for James's design is that it is the least harmful of all the alternatives, especially the FeedSync design. > The feed abstraction for Atom and RSS is one of a > feed+metadata and a stream of entries+metadata - this has > been the case for the last 10 years, and it isn't going to > change now. The model is not, as would be required if were > to mix entry and feed metadata, a feed+metadata and a stream of > entries+metadata + associations with every feed document that > that entry > entries+has > ever been part of just in case there is some sort of > misplaced entry metadata hidden at feed level, so that > clients looking at an entry can manually reimplement the > sliding window mechanism for tombstones or whatever. Urgh. Implementations are free to ignore the tombstones and have the exact same behavior that they have now. That is the primary benefit of this design over the FeedSync one. - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 18:42:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBf8F-0008SK-Ae for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:42:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBf8D-0002vA-0P for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:42:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06NVVaS018268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 16:31:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06NVVxP018267; Sun, 6 Jan 2008 16:31:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06NVUHQ018260 for ; Sun, 6 Jan 2008 16:31:31 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=Glh85//SG1AUuJP8YnJDNlWY17lUxvQ/AzX3rA63XGVYrrwdLDyzN yf1cbl6BdBD6OVb8oBybVxagMw/OquBRJfYrdjSEwa9jN4suEiMLM 5Dw1k0YQt/EUAoV6DFiLtkOyaWINsFA1RTpKaHJ7r8Hr3sG5+Qucn 1kh0TBaZ3kug=; Received: from wb5-a.mail.utexas.edu ([128.83.126.142]) by ironman.mail.utexas.edu with ESMTP; 06 Jan 2008 17:31:24 -0600 Received: (qmail 35623 invoked from network); 6 Jan 2008 23:31:24 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb5.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 6 Jan 2008 23:31:24 -0000 Date: Sun, 6 Jan 2008 17:31:23 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: David Powell cc: "'Brian Smith'" , "'atom-syntax'" Subject: RE: Tombstones In-Reply-To: <003701c850b6$0fed50a0$2fc7f1e0$@net> Message-ID: References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> <000001c850aa$74b60f10$0301a8c0@T60> <003701c850b6$0fed50a0$2fc7f1e0$@net> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Sun, 6 Jan 2008, David Powell wrote: > No there isn't, and practically anything is syntactically valid according to > the spec. But, I'm not replying to these posts to save people from reading > the spec, but to highlight the harmful effects of these extensions. I > believe that violating the separation between entry and feed metadata breaks > a large and useful category of applications and that approving such > behaviour would be extremely damaging to the Atom community. Agreed 100%. > > The feed abstraction for Atom and RSS is one of a feed+metadata and a stream > of entries+metadata - this has been the case for the last 10 years, and it > isn't going to change now. The model is not, as would be required if were Yes -- it's that easy to grok abstraction that makes Atom (and RSS) "work". --peter keane > to mix entry and feed metadata, a feed+metadata and a stream of > entries+metadata + associations with every feed document that that entry has > ever been part of just in case there is some sort of misplaced entry > metadata hidden at feed level, so that clients looking at an entry can > manually reimplement the sliding window mechanism for tombstones or > whatever. Urgh. > > -- > Dave > > From owner-atom-syntax@mail.imc.org Sun Jan 06 18:58:03 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBfNT-0003P7-PU for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:58:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBfNS-00034t-5O for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 18:58:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Nivsd018801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 16:44:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06NivUY018800; Sun, 6 Jan 2008 16:44:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06NiuEp018794 for ; Sun, 6 Jan 2008 16:44:56 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=Qk0hDnEeRNNo35QRMTwHYWPFbe/Ol2jkQwSOyXY5JeSB2D7K9on4I UsAW9KJDs967KXclxsZzNwhjb4zEP7BA/H/jFob36ekkdoTXUSTiY fBWQV20rNiWzwAwXz5Y31AlG8BFCs3KEu5ILegP2/wiuBMLjz5ZPz lnzFagp6/axY=; Received: from wb4-a.mail.utexas.edu ([128.83.126.140]) by ironman.mail.utexas.edu with ESMTP; 06 Jan 2008 17:44:56 -0600 Received: (qmail 56931 invoked from network); 6 Jan 2008 23:44:55 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb4.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 6 Jan 2008 23:44:55 -0000 Date: Sun, 6 Jan 2008 17:44:55 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: Brian Smith cc: "'atom-syntax'" Subject: RE: Tombstones In-Reply-To: <000001c850cb$78875f60$0701a8c0@T60> Message-ID: References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> <000001c850aa$74b60f10$0301a8c0@T60> <003701c850b6$0fed50a0$2fc7f1e0$@net> <000001c850cb$78875f60$0701a8c0@T60> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Sun, 6 Jan 2008, Brian Smith wrote: > [snip] > Could you please give an example of such harm. The rationale for James's > design is that it is the least harmful of all the alternatives, > especially the FeedSync design. > Because the "feed abstraction" is that much more complicated. Why is a bit of metadata as a child of an "entry" element a non-starter? "deleted","moved", etc. are just attributes of an entry (and there IS a category element available...). Obviously I don't believe that a tomstone is anything but another kind (or state) of (an) entry. >> The feed abstraction for Atom and RSS is one of a >> feed+metadata and a stream of entries+metadata - this has >> been the case for the last 10 years, and it isn't going to >> change now. The model is not, as would be required if were >> to mix entry and feed metadata, a feed+metadata and a stream of >> entries+metadata + associations with every feed document that >> that entry >> entries+has >> ever been part of just in case there is some sort of >> misplaced entry metadata hidden at feed level, so that >> clients looking at an entry can manually reimplement the >> sliding window mechanism for tombstones or whatever. Urgh. > > Implementations are free to ignore the tombstones and have the exact > same behavior that they have now. That is the primary benefit of this > design over the FeedSync one. Yes, and then what sort of extension will be proposed for the folks who want a "deleted" feature, but need/want to keep the deleted entry AS an entry. --peter > > - Brian > From owner-atom-syntax@mail.imc.org Sun Jan 06 19:09:49 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBfYr-0006r8-FN for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:09:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBfYq-0003Ci-VW for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:09:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06NwAKa019134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 16:58:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m06NwAEn019133; Sun, 6 Jan 2008 16:58:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m06Nw7hA019127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 16:58:10 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id B84EC23E4AE for ; Sun, 6 Jan 2008 18:58:06 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> <000001c850aa$74b60f10$0301a8c0@T60> <003701c850b6$0fed50a0$2fc7f1e0$@net> <000001c850cb$78875f60$0701a8c0@T60> Subject: RE: Tombstones Date: Sun, 6 Jan 2008 18:01:59 -0800 Message-ID: <000101c850d1$4c11c8c0$0701a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AchQviVOTDeDQ2fLSIikaGRSx233PQAEpugg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Peter Keane wrote: > On Sun, 6 Jan 2008, Brian Smith wrote: > > > [snip] > > Could you please give an example of such harm. The rationale for > > James's design is that it is the least harmful of all the > > alternatives, especially the FeedSync design. > > > > Because the "feed abstraction" is that much more complicated. I disagree that it is a significant complication, and even if it was, I fail to see the actual harm caused. > Why is a bit of metadata as a child of an "entry" element a > non-starter? James and I have explained this in this thread multiple times. If you disagree with our reasoning, that is fine, but let's not keep running in circles. > > Implementations are free to ignore the tombstones and have > > the exact same behavior that they have now. That is the primary > > benefit of this design over the FeedSync one. > > Yes, and then what sort of extension will be proposed for the > folks who want a "deleted" feature, but need/want to keep the > deleted entry AS an entry. I suggest using FeedSync, if that is what you want. It has a lot of nice features besides tombstones. - Brian From owner-atom-syntax@mail.imc.org Sun Jan 06 19:22:49 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBflR-00018w-6m for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:22:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBflP-0003LB-KE for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:22:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070C4JA019714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 17:12:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m070C46H019713; Sun, 6 Jan 2008 17:12:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070C2Ij019707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 17:12:03 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.110] (unknown [121.44.238.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 33FD923E49E; Sun, 6 Jan 2008 19:12:00 -0500 (EST) Cc: "'Brian Smith'" , "'atom-syntax'" Message-Id: <4D9DEFD0-97BE-4E6D-A83A-B71F4257E6F5@mnot.net> From: Mark Nottingham To: David Powell In-Reply-To: <003701c850b6$0fed50a0$2fc7f1e0$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Tombstones Date: Mon, 7 Jan 2008 11:11:48 +1100 References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <4768122A.3050801@gmail.com> <477A4F49.5070900@dehora.net> <477A7C87.4090906@gmail.com> <477A9BC1.4000407@dehora.net> <20080101202448.GL564@klangraum> <477AC15F.1010104@dehora.net> <477ADEA8.1040307@gmail.com> <477AEA91.4010401@dehora.net> <477B23F3.1010003@gmail.com> <477C3A37.2030602@gmail.com> <000001c850aa$74b60f10$0301a8c0@T60> <003701c850b6$0fed50a0$2fc7f1e0$@net> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 I'm having trouble seeing how this is relevant at all. If an implementation doesn't implement tombstones, they'll ignore them. If it chokes on them because they don't recognise them, or treat them as if they're entries, that implementation is broken as per section six, where all of this is very explicitly laid out. What's the problem? On 07/01/2008, at 9:46 AM, David Powell wrote: > No. What a metadata element is "about" has no direct implications on > implementations, but the implied life-cycle of the metadata and > entities > involved (entry and feed) do. > > Say you poll a feed URI twice, you might get back entry 1,2,3 in the > first > poll, and entry 2,3,4 in the second poll. Stateful Atom > implementations > will need to store entries that aren't in the most recent polling of > the > feed URI. This requires entry and feed state to be decoupled. A good > example is Microsoft's Feed Platform, which downloads feeds, and > presents > them to client applications via an API that allows the entries of a > feed > (including metadata elements) to be accessed as XML structures. > > If you start putting entry metadata elements at level this > simply > won't work. Perhaps Windows Feed Platform is faulty for not > anticipating > James's latest proposal, but I don't think so. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sun Jan 06 19:32:45 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBfv3-0007Fy-NT for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:32:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBfv3-0003RJ-7s for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:32:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070LjQp020042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 17:21:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m070LjxQ020041; Sun, 6 Jan 2008 17:21:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070LhfE020034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 17:21:44 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.110] (unknown [121.44.238.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 64C7B23E4BA; Sun, 6 Jan 2008 19:21:42 -0500 (EST) Cc: atom-syntax Message-Id: <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> From: Mark Nottingham To: Bill de hOra In-Reply-To: <477D2328.80609@dehora.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft Date: Mon, 7 Jan 2008 11:21:29 +1100 References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca The sentence afterwards is a bit more revealing; > The Atom namespace is reserved for future forward-compatible > revisions of Atom. Future versions of this specification could add > new elements and attributes to the Atom markup vocabulary There are two ways to read this; 1) Future RFCs that completely replace RFC4287 are the only ones allowed to add new elements and attributes. 2) Future RFCs that update RFC4287 are allowed to add new elements and attributes. Given that we allow pretty much anybody to rock up and add a link relation with IESG approval, it doesn't seem like a far stretch to me to say that #2 is the right reading, given that the only real difference between the two is regarding document structure (i.e., the whole doc + extension, or just extension). In other words, by the logic of #1, the only thing James would have to do is to copy RFC4287, add a section on tombstones, and push it through the process. That seems pointlessly tortured, to say the least. I think the most you could say is that #2 needs IESG approval via a standards-track RFC (again, notice the parity with the link relation registry), but that's already assumed in the discussions I've seen here. But that's just my .02. On 04/01/2008, at 5:02 AM, Bill de hOra wrote: > > Mark Nottingham wrote: >> On 03/01/2008, at 3:33 PM, Bill de hOra wrote: >>>> >>>> 1. deleted-entry is now part of the Atom namespace >>> >>> "The Atom namespace is reserved for future forward-compatible >>> revisions of Atom." RFC4287, 6.2. >> ... which begs the question: does this qualify as such? > > Not if the word "revision" means what I think it does. > > cheers > Bill > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sun Jan 06 19:42:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBg4G-0001wT-OI for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:42:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBg4G-0003X8-8U for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:42:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070VqH4020473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 17:31:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m070VqLP020472; Sun, 6 Jan 2008 17:31:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070Vp8P020465 for ; Sun, 6 Jan 2008 17:31:52 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id E3A1DDE595 for ; Mon, 7 Jan 2008 00:31:50 +0000 (UTC) Message-ID: <478172F4.4060005@dehora.net> Date: Mon, 07 Jan 2008 00:31:48 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "'atom-syntax'" Subject: Re: Feed Paging for Efficient Feed Synchronization References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com> <002001c8388a$90c65b20$2501a8c0@Junk> <475A288F.10301@gmail.com> <003a01c839ae$bac27ce0$2101a8c0@Junk> <477A5159.2080708@dehora.net> <001f01c850b7$739745b0$0701a8c0@T60> In-Reply-To: <001f01c850b7$739745b0$0701a8c0@T60> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Brian Smith wrote: > Let's say I have this at time T: > Page: (prev) > Entry A > Entry B > Page: (current) > Entry C > Entry D > Page: (next) > Entry E > Entry F > > I page through the feed and I am on the second page. Entry E gets updated before I nagivate to the next page page: > > Page: > Entry E > Page: (prev) > Entry A > Entry B > Page: (current) > Entry C > Entry D > Page: (next) > Entry F > > Is this still "stable"? Or does stability require snapshot semantics, like this?: That's CAP. Pick two. cheers Bill From owner-atom-syntax@mail.imc.org Sun Jan 06 19:57:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBgIp-0003rv-E3 for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:57:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBgIo-0003gI-W6 for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:57:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070l34X021146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 17:47:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m070l3PN021143; Sun, 6 Jan 2008 17:47:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070l2p1021123 for ; Sun, 6 Jan 2008 17:47:03 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 2EB1ADDE64 for ; Mon, 7 Jan 2008 00:47:01 +0000 (UTC) Message-ID: <47817683.9090300@dehora.net> Date: Mon, 07 Jan 2008 00:46:59 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> In-Reply-To: <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Mark Nottingham wrote: > The sentence afterwards is a bit more revealing; > >> The Atom namespace is reserved for future forward-compatible revisions >> of Atom. Future versions of this specification could add new elements >> and attributes to the Atom markup vocabulary > There are two ways to read this; > > 1) Future RFCs that completely replace RFC4287 are the only ones allowed > to add new elements and attributes. > 2) Future RFCs that update RFC4287 are allowed to add new elements and > attributes. > > Given that we allow pretty much anybody to rock up and add a link > relation with IESG approval, it doesn't seem like a far stretch to me to > say that #2 is the right reading, given that the only real difference > between the two is regarding document structure (i.e., the whole doc + > extension, or just extension). > > In other words, by the logic of #1, the only thing James would have to > do is to copy RFC4287, add a section on tombstones, and push it through > the process. That seems pointlessly tortured, to say the least. > > I think the most you could say is that #2 needs IESG approval via a > standards-track RFC (again, notice the parity with the link relation > registry), but that's already assumed in the discussions I've seen here. > > But that's just my .02. If there's a good technical or social reason to put tombstones into the atom namespace, let's hear it. cheers Bill From owner-atom-syntax@mail.imc.org Sun Jan 06 19:59:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBgKg-0001it-C2 for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:59:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBgKf-0003hQ-NS for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 19:59:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070n9OM021209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 17:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m070n9YQ021208; Sun, 6 Jan 2008 17:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070n77e021202 for ; Sun, 6 Jan 2008 17:49:08 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4979634rvf.34 for ; Sun, 06 Jan 2008 16:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Gs8KOl7NwFvF83Gy3UFvhJSujAWXQHjnUmGKK2ITTF8=; b=u7KSHKSeN4AjhMmOgWRfi4Zu7vK7y20VVAACPUCTllDVtGjOnEQIqL7E+SoJkyRbw5rnR4ziunCJq+0h5w0x/5oTdt1XG1PiTGBy++eTkUtap0crwWrqu7M4NdYVMFlzN9qfInqZjGC345yi+1jfbSpeEYXKsz2XBTkKqLQyiUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=CtPQFaccAea/rrxek746qdhu2A7ydbE94Njsm689dIupuxki6ga+LZpcs+fsv/1SJ1WfSDwX/wcgO1YrX7pH0aDnMIBQoWL/MsqlU31cCoU7h4SyD83k6SaNsykyQY7pahQRdkLJ/HjQaFvwUnRX0nhT/4xOVk8iZcyra8taPAo= Received: by 10.140.88.11 with SMTP id l11mr7678768rvb.237.1199666947455; Sun, 06 Jan 2008 16:49:07 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id k2sm3990765rvb.36.2008.01.06.16.49.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 16:49:06 -0800 (PST) Message-ID: <47817700.4030706@gmail.com> Date: Sun, 06 Jan 2008 16:49:04 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: David Powell CC: "'Brian Smith'" , "'atom-syntax'" Subject: Re: Proposal: Atomext WG References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> In-Reply-To: <003601c850b6$0c3b6c30$24b24490$@net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be David Powell wrote: > > Brian Smith wrote: > >>> The WG will initially focus on the review of existing >>> proposals for standards track extensions including: >>> >>> * Atom Bidi Extension, draft-snell-atompub-bidi-05 >> How much of a problem is BIDI in Atom today? (This isn't a rhetorical >> question). Atom documents are almost never hand-entered, and there is >> already a specification in place for markup up BIDI and even ruby text >> in general XML. The odds that clients and servers are going to >> correctly implement this extension--except those targeted direclty >> towards BIDI users--seem pretty low to me. Personally, it seems much >> easier to implement the an existing BIDI markup mechanism (Unicode, >> XML, and/or XHTML) than a new standard. > > I agree. We already have HTML - which supports much more > internationalization features than just bidi. We also have > Unicode bidi controls, for people who don't want to use HTML > for whatever reason. Do we really need 3 different interacting > implementations of bidi? This proposal will just cause interop > problems when people try to use it with implementations that don't > yet support it, when those people could probably have just used the > HTML or Unicode techniques with more success. This has been covered many times in the past. The xhtml mechanisms do not help when we're dealing with bidi text in attributes like atom:link/title and atom:category/label, the various plain text elements, and extensions. Second, when dealing with (x)html text and content, the specification specifically recommends using the bidi mechanisms native to each. Third, neither Unicode or the W3C recommend using the Unicode bidi formatting codes are not recommended in markup, for a variety of reasons. The fact that Atom will typically be created by software doesn't solve the problem. Fourth, even with the Unicode formatting codes, there are existing deployed feed readers that get it wrong. Fifth, the bidi attribute defined in the spec does not introduce any additional interop issues. Client implementations that do not support it will continue to act exactly as they do today. If intermediaries drop the attribute on the floor, no critical data is lost and no existing applications will be broken. I know this for a fact because I have about 100k internal Atom feeds that are currently using the bidi attribute and have been since May of last year. > > And isn't the purpose of bidi markup usually to clarify ambiguities that > would arise from applying the Unicode bidi algorithms? To do that you need > to be able to mark up the interior of these text-only elements, which this > proposal wouldn't support anyway. > Again, existing bidi markup does not help us outside of (x)html text and content elements. The goal of this specification is to provide a means of indicating the text direction without changing the way existing implementations work -- meaning that existing implementations that do not support the extension will continue working as they always have while implementations that do support the extension can realize it's benefits. > [snip] > > If we really need support for Ruby and bidi in , and we aren't > immediately intending to supercede RFC4287, I think we would be better > adding an additional entry/person metadata element that supports HTML names. And how would that help us with atom:link/@title and atom:category/@label? > But to be honest, I'd like to see people knocking on our doors before we start > writing drafts to solve potential problems. > Ok, I'm knocking. This is not a potential problem. I implement and support existing deployed software that publishes feeds with bidi text. I've seen the rendering problems first hand. There's nothing potential about it. - James From owner-atom-syntax@mail.imc.org Sun Jan 06 20:06:45 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBgRx-0004bk-Ld for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 20:06:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBgRx-0003n2-8U for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 20:06:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070uwfL021467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 17:56:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m070uwNw021466; Sun, 6 Jan 2008 17:56:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m070uuWq021460 for ; Sun, 6 Jan 2008 17:56:57 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4981473rvf.34 for ; Sun, 06 Jan 2008 16:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=uffiRrGSD810Kxgric0WN3NMtiMF3kLqqSDAFC8NWyg=; b=gyyYor+nx34SadMQREk1NSF5IZqENOqcLrKX3t8uwG9jLmGYtT11vTf3Q0+S3IwENqyBITUhsIJcmxgjFiq5rLpdIcQHYd7+NoWvXOkiZ49moul9U3GksP5ZHzhEZwMQgxu/aHSn768PTuvGRGHfRyJ0e7bgTs9MjaWua6w5GYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=DvdmHJypFoabbq70+iUeenAM0Z+QtTb6U1T37niW/nBjVkmt8xb98/OnSI5TKq61meTT1wqf//d1z91O1TFXnuk/yBMwgr9Oe7w1VPz5lJhwIv/l6fJAYLviH4PQw+scsorSpiLQEnzOGLh7t7/Ajtab0qANM3eCy8ys2ylDBSU= Received: by 10.141.115.6 with SMTP id s6mr2484990rvm.47.1199667416639; Sun, 06 Jan 2008 16:56:56 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id l31sm4004581rvb.27.2008.01.06.16.56.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 16:56:55 -0800 (PST) Message-ID: <478178D6.8000301@gmail.com> Date: Sun, 06 Jan 2008 16:56:54 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> <47817683.9090300@dehora.net> In-Reply-To: <47817683.9090300@dehora.net> X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Let's forget about the tombstone draft for a minute. If there are good technical and social reasons to add any elements or attributes to the Atom namespace, what would they be? - James Bill de hOra wrote: > [snip] > > If there's a good technical or social reason to put tombstones into the > atom namespace, let's hear it. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Sun Jan 06 20:22:45 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBghR-0007fB-2n for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 20:22:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBghQ-0003x6-Hc for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 20:22:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m071BIa2022180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 18:11:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m071BIF0022179; Sun, 6 Jan 2008 18:11:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m071BGxx022173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 18:11:17 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 06E5AD05AF; Sun, 6 Jan 2008 20:11:12 -0500 (EST) Cc: atom-syntax Message-Id: From: Mark Nottingham To: Bill de hOra In-Reply-To: <47817683.9090300@dehora.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft Date: Mon, 7 Jan 2008 12:11:08 +1100 References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> <47817683.9090300@dehora.net> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c On 07/01/2008, at 11:46 AM, Bill de hOra wrote: > > Mark Nottingham wrote: >> The sentence afterwards is a bit more revealing; >>> The Atom namespace is reserved for future forward-compatible >>> revisions of Atom. Future versions of this specification could add >>> new elements and attributes to the Atom markup vocabulary >> There are two ways to read this; >> 1) Future RFCs that completely replace RFC4287 are the only ones >> allowed to add new elements and attributes. >> 2) Future RFCs that update RFC4287 are allowed to add new elements >> and attributes. >> Given that we allow pretty much anybody to rock up and add a link >> relation with IESG approval, it doesn't seem like a far stretch to >> me to say that #2 is the right reading, given that the only real >> difference between the two is regarding document structure (i.e., >> the whole doc + extension, or just extension). >> In other words, by the logic of #1, the only thing James would have >> to do is to copy RFC4287, add a section on tombstones, and push it >> through the process. That seems pointlessly tortured, to say the >> least. >> I think the most you could say is that #2 needs IESG approval via a >> standards-track RFC (again, notice the parity with the link >> relation registry), but that's already assumed in the discussions >> I've seen here. >> But that's just my .02. > > If there's a good technical or social reason to put tombstones into > the atom namespace, let's hear it. As I think I said before, it's not a big deal either way; I just don't want people to walk away thinking that *no* extension can be in the atom namespace. Whether or not Tombstones in particular belong in the Atom namespace is mostly a question of how common we think they'll be once deployed, across a variety of use cases. Personally, I think that there's potential for them to be widely deployed across a number of use cases. In a way, both tombstones and feed history feel like 'missing' parts of atom (but I realise that from some perspectives, that can be said of almost any extension). Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sun Jan 06 20:35:49 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBgu5-0005L5-1c for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 20:35:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBgu4-00045M-Ct for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 20:35:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m071OaNn023262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 18:24:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m071OaVG023261; Sun, 6 Jan 2008 18:24:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m071OZsK023255 for ; Sun, 6 Jan 2008 18:24:35 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so4987533rvf.34 for ; Sun, 06 Jan 2008 17:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=qWUz5WlGYWuBORCmymFaynI6JwGXALiMDECt1YK/vug=; b=JYDRGzokNNejOTLyqlQ+6HB/lDe9CiGkUB5XrlJBCFIUW9FK3EsCN1dlY6BcR1gn7i35sirptzDG72Mvp6LiXez6KLGf7R7I1OXxyYbDrC3UlkN/rVB9gvY1eyBKESJTTNkchnMJ6cuZNzhVlK1wfb/v0V1xkBUZ54KHF40LAQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=aLJ7iWYwbF6lyIQCWkmwUKmXvM1Dg7y5m1SO3K8eBKJOb9eOgcrPwXQBKO1V9CnUcyFS1yfcBzwgK4g0TV2v3FLUCOg7BWjXs9FXCsFJXhaGpN0O82zWgWHphxWB0rZvOzOLcXM3IBVK57hJTKPZQ8FcThqcMUR7ZCNc7Oh967Q= Received: by 10.141.179.5 with SMTP id g5mr10284447rvp.76.1199669075151; Sun, 06 Jan 2008 17:24:35 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id g22sm9486681rvb.5.2008.01.06.17.24.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 17:24:34 -0800 (PST) Message-ID: <47817F50.2070409@gmail.com> Date: Sun, 06 Jan 2008 17:24:32 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: Proposal: Atomext WG References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> In-Reply-To: <000101c850ab$31d0db20$0301a8c0@T60> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Brian Smith wrote: > [snip] > I think it makes more sense to get people to get some working > implementations that have informally agreed on some extensions, I implemented extended bidi support in Apache Abdera months ago; and our internal blogging environment supports bidi entries. > [snip] > How much of a problem is BIDI in Atom today? (This isn't a rhetorical question). It's a problem. Quite a few readers I have tested do not even properly support bidi markup used in entry title's that use (x)html and there are language-sensitive attributes in the Atom schema that cannot use the existing markup oriented solutions at all; and since the values for those attributes are typically provided by humans, relying on the software to properly insert the unicode formatting codes (which aren't recommended for markup in the first place) is problematic at best. Fortunately, there are ways of guessing the text direction with fairly decent accuracy given the value of xml:lang. That is, the language or script identified could be RTL. However, it's not always clear and guessing is not always accurate. The bidi attribute gives us a good, explicit fallback. > Atom documents are almost never hand-entered, and there is already a specification > in place for markup up BIDI and even ruby text in general XML. The odds that clients > and servers are going to correctly implement this extension--except those targeted > direclty towards BIDI users--seem pretty low to me. Personally, it seems much easier > to implement the an existing BIDI markup mechanism (Unicode, XML, and/or XHTML) than > a new standard. > What are you basing that on? There's really not much guess work involved in the implementation and apps that choose not to implement support will be no worse or better off than they are currently. > Most Atom constructs that hold human-readable text allow for XHTML, which > has its own BIDI mechanism. The main problem seems to be with person > constructs, and with extension elements. The Atom BIDI draft doesn't solve > the internationalization problems with person constructs because it doesn't > provide a way to do Ruby text markup, which is especially important for atom:name. Don't forget atom:link/@title and atom:category/@label. atom:category/@term can also cause problems when implementation use that value for display purposes. Arbitrary extension elements can also have problems. The bidi draft doesn't attempt to solve all the i18n issues with Atom. Ruby text is a problem for pretty much everything, especially given the fact that most browsers don't have a clue how to properly render ruby text yet. The bidi draft rightfully focuses on one small part of the problem. > It also doesn't solve the problem with atom:link/@title or other attributes that > are language-sensitive. Yes, it does. - James From owner-atom-syntax@mail.imc.org Sun Jan 06 21:36:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBhrD-0007ym-Tx for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 21:36:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBhrC-0004pp-D6 for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 21:36:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m072N3eU026496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 19:23:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m072N3C2026495; Sun, 6 Jan 2008 19:23:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from djpowelldev.dyndns.org (djpowelldev.dyndns.org [84.244.12.152]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m072N09n026487 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 6 Jan 2008 19:23:03 -0700 (MST) (envelope-from dave@djpowell.net) Received: from localhost ([127.0.0.1] helo=eeepc-davidpowe.djpowell.net) by djpowelldev.dyndns.org with esmtp (Exim 4.34) id 1JBhdd-0001yL-Ls; Mon, 07 Jan 2008 02:22:54 +0000 From: David Powell To: James M Snell Cc: "'Brian Smith'" , "'atom-syntax'" Subject: Bidi (was: Proposal: Atomext WG) In-Reply-To: <47817700.4030706@gmail.com> (James M. Snell's message of "Sun, 06 Jan 2008 16:49:04 -0800") References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> <47817700.4030706@gmail.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Date: Mon, 07 Jan 2008 02:24:47 +0000 Message-ID: <87wsqmwexc.fsf_-_@djpowell.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 James M Snell writes: Well answered! Thanks for the patience, you've convinced me. Constructive criticism now - could you explain this: Implementers are reminded that unexpected results could occur when using both the "dir" attribute and the Unicode control characters within a single document. Isn't using both the expected, and only, way to mark-up bidi text when the Unicode heuristics won't do a good enough job? It seems a bit odd to warn against using the feature as intended? > Third, neither Unicode or the W3C recommend using the Unicode bidi > formatting codes are not recommended in markup, for a variety of > reasons. True, but I'm not sure I'd describe a plain text element content or attribute value as markup. Isn't markup something that could alternatively contain tags, and be "marked-up"? Given that these locations can't, the Unicode bidi codes will need to be used regardless, so I'm not sure whether those recommendations apply here? > Fourth, even with the Unicode formatting codes, there are existing > deployed feed readers that get it wrong. And will continue to. -- Dave From owner-atom-syntax@mail.imc.org Sun Jan 06 22:07:45 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBiL3-00030G-6L for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 22:07:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBiL2-0005CC-Dl for atompub-archive@lists.ietf.org; Sun, 06 Jan 2008 22:07:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m072reeN028441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 19:53:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m072reS9028440; Sun, 6 Jan 2008 19:53:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m072rcnP028434 for ; Sun, 6 Jan 2008 19:53:39 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1368056anc.44 for ; Sun, 06 Jan 2008 18:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=IguPiUY0L6Qc9zDbbRTnTavogaKX3mLEKwkJs/oTuxc=; b=prtzAIMQtdMyDDYCXSMNxvODngGzvRcAOtoOmhJJq5OIbrKxwkYoORAVdA1vkdRk6t6acS6hXxcvAe1dN8X2SID2g05dl0U5bMx1uWQiF+/dYwgUpAk6SOHfVL2fKgM5jWPlxcVGnmftmpQyY6uNObAbsBbmqo2g2XZ0FCgHGow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=kbNK/wp91PDRfZpD4SDGRGUaGvBPlQAmPWFKvP8ZnYvshM28BYvY6vlkVHZFmxP67wxXMIShQj/mLE9KhCV9N3Ix7fF/dlnW0htMRaqHMG+qlpDX1s9tvcKOcqr1tlxNOhVXw6DhXp32BfeC8H15IjrcQ/Kgo6fqwbV4hcXtM44= Received: by 10.100.225.19 with SMTP id x19mr41454145ang.9.1199674418501; Sun, 06 Jan 2008 18:53:38 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id c78sm15359839hsa.15.2008.01.06.18.53.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 18:53:38 -0800 (PST) Message-ID: <4781942F.1010806@gmail.com> Date: Sun, 06 Jan 2008 18:53:35 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: David Powell CC: "'Brian Smith'" , "'atom-syntax'" Subject: Re: Bidi References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> <47817700.4030706@gmail.com> <87wsqmwexc.fsf_-_@djpowell.net> In-Reply-To: <87wsqmwexc.fsf_-_@djpowell.net> X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 David Powell wrote: > James M Snell writes: > > Well answered! Thanks for the patience, you've convinced me. > Good to hear. > Constructive criticism now - could you explain this: > > Implementers are reminded that unexpected results could occur when > using both the "dir" attribute and the Unicode control characters > within a single document. > > Isn't using both the expected, and only, way to mark-up bidi text when > the Unicode heuristics won't do a good enough job? It seems a bit odd > to warn against using the feature as intended? > No, both should not be used. > >> Third, neither Unicode or the W3C recommend using the Unicode bidi >> formatting codes are not recommended in markup, for a variety of >> reasons. > > True, but I'm not sure I'd describe a plain text element content or > attribute value as markup. Isn't markup something that could > alternatively contain tags, and be "marked-up"? Given that these > locations can't, the Unicode bidi codes will need to be used > regardless, so I'm not sure whether those recommendations apply here? > The markup in question here are the Atom elements. In other words, the bidi formatting characters should not be used in XML, period, not just within specific kinds of elements. >> Fourth, even with the Unicode formatting codes, there are existing >> deployed feed readers that get it wrong. > > And will continue to. > Yep. - James From owner-atom-syntax@mail.imc.org Mon Jan 07 00:46:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBkp0-0005Rr-Ti for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 00:46:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBkoy-0006iP-SS for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 00:46:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m075NO3b034917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 22:23:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m075NONj034916; Sun, 6 Jan 2008 22:23:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m075NGTX034899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 22:23:16 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id BE97F23E4A1 for ; Mon, 7 Jan 2008 00:23:15 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Sun, 6 Jan 2008 23:27:05 -0800 Message-ID: <000101c850fe$b7d16d90$0701a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchQzETt132MEUFmSue6kg7ODIBz3wAIpNAg In-Reply-To: <47817F50.2070409@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m075NHTW034904 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a James M Snell wrote: > Brian Smith wrote: > > [snip] > > I think it makes more sense to get people to get some working > > implementations that have informally agreed on some extensions, > > I implemented extended bidi support in Apache Abdera months > ago; and our internal blogging environment supports bidi entries. That is a definitely a positive first step. What other implementations does Abdera interoperate with with regard to BIDI text? > > How much of a problem is BIDI in Atom today? (This isn't a > rhetorical question). > > It's a problem. Quite a few readers I have tested do not even > properly support bidi markup used in entry title's that use > (x)html. That is exactly my point. People are not even implementing the current standards for BIDI text. Adding another standard to implement is not going to make the situation better. > Since the values for those attributes > are typically provided by humans, relying on the software to > properly insert the unicode formatting codes (which aren't > recommended for markup in the first place) is problematic at best. If the software cannot correctly insert the formatting codes into the document, how would it be able to insert the correct directionality markup? > > Atom documents are almost never hand-entered, and there is > > already a specification in place for markup up BIDI and even > > ruby text in general XML. The odds that clients and servers > > are going to correctly implement this extension--except > > those targeted direclty towards BIDI users--seem pretty > > low to me. Personally, it seems much easier to > > implement the an existing BIDI markup mechanism (Unicode, > > XML, and/or XHTML) than a new standard. > > What are you basing that on? The Unicode/W3C guidelines (http://www.w3.org/TR/unicode-xml/#Bidi and http://www.w3.org/International/questions/qa-bidi-controls) say this: * Use *XHTML* BIDI markup whenever possible. * Otherwise *CSS* whenever possible. * Otherwise, consider building BIDI markup into your markup schema. * We have to support BIDI formatting codes anyway, since the above mechanisms don't solve all BIDI problems. > There's really not much guess work > involved in the implementation and apps that choose not to implement > support will be no worse or better off than they are currently. That is not true. Consider a feed aggregator. If it doesn't support Atom BIDI, then it will not correctly rewrite entries to handle an inherited "dir" attribute from the atom:feed element. Since the directionality is also inherited by text constructs, whenever the implementation passes the text construct to a rendering engine, it needs to rewrite that content to handle the inherited directionality. > Don't forget atom:link/@title and atom:category/@label. > atom:category/@term can also cause problems when > implementation use that > value for display purposes. I know that. But, the Atom BIDI draft does not eliminate all uses of BIDI formatting characters in these attributes, either. And, it doesn't specify BIDI support for language-sensitive content in Atom service documents, category documents, RSS feeds, or RSD documents. > Arbitrary extension elements can also have problems. The BIDI draft says it only applies to constructs that RFC4287 labeled "language sensitive." Accordingly, the BIDI draft does not apply to extension elements. > The bidi draft doesn't attempt to solve all the i18n issues > with Atom. Ruby text is a problem for pretty much everything, > especially given the fact that most browsers don't have a > clue how to properly render ruby text yet. The bidi draft > rightfully focuses on one small part of the problem. I agree that a narrow scope is good. But, a solution for Ruby text will also be applicable to BIDI, especially if that solution involves the reuse of XHTML markup and/or CSS. > > > It also doesn't solve the problem with atom:link/@title or > other attributes that > > are language-sensitive. > > Yes, it does. The Atom BIDI draft does not provide a way of specifying base different base directionalities for attributes on the same element, it doesn't eliminate all need for BIDI formatting characters in language-sensitive attribute values, it doesn't provide a mechanism for discovering which (nested) extension elements and attributes are affected by the proposed Atom BIDI markup. If I implement RFC4287, the Unicode BIDI algorithm, XHTML BIDI, HTML BIDI, and the "Unicode in XML" guidelines, I will have pretty good BIDI support. It will require me to adhere to four different BIDI standards in addition to RFC4287. That is a lot of work already. Now, your Atom BIDI and URI template BIDI proposals add two more specifications that I would have to support--for a total of SIX standards to adhere to and resolve conflicts between, JUST to support BIDI text. And, even if I create well-formed documents adhering to all six standards, whenever I open them up in any of my text editors, or any feed reader, they will look wrong since nobody else is implementing all of those standards. I think that is totally unreasonable. Abdera might have amazing support for BIDI, for which you should be commended, but unless all Atom software is going to be implemented on top of Abdera, Abdera will not be able to reliably interoperate with anything. If we want to provide interopera! ble support for BIDI, we need to make it as simple to implement as possible. My counter-proposal is simple: * Use XHTML/HTML BIDI/Ruby markup whenever possible. * Otherwise, use Unicode BIDI/Ruby formatting codes, such that matching pairs of formatting codes are fully contained within a single text or attribute node. * Editors of new documents must be meticulous about inserting the proper markup and formatting codes. * Processors of existing documents must be meticulous about preserving BIDI/Ruby markup and/or formatting codes whenever any part of the contained text is preserved. I recognize that this goes against the Unicode in XML guidelines. However, Atom already goes against the guidelines by having language-sensitive text in attribute values and other contexts where XHTML markup cannot be used. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 00:49:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBkr7-0001Hf-IL for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 00:49:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBkr7-0006jc-1t for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 00:49:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m075NHfD034911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 22:23:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m075NHgU034910; Sun, 6 Jan 2008 22:23:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m075NFVT034897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 22:23:16 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 05F7023E496 for ; Mon, 7 Jan 2008 00:23:14 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> Subject: Markup in atom:name (was RE: Proposal: Atomext WG) Date: Sun, 6 Jan 2008 23:27:05 -0800 Message-ID: <000001c850fe$b763deb0$0701a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchOYHqN7W10DySoS+yc+pV3ecKeRgCRys7gAAJewiAAEgmnsA== In-Reply-To: <003601c850b6$0c3b6c30$24b24490$@net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m075NGVS034900 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb David Powell wrote: > Brian Smith wrote: > If we really need support for Ruby and bidi in , > and we aren't immediately intending to supercede RFC4287, I > think we would be better adding an additional entry/person > metadata element that supports HTML names. But to be honest, > I'd like to see people knocking on our doors before we start > writing drafts to solve potential problems. I have Japanese users and Japanese language learners that make extensive use of Ruby markup as an instructional device for teaching Kanji (the complex Japanese characters). http://tools.ietf.org/html/rfc4287#section-6.4: Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden. http://tools.ietf.org/html/rfc4287#section-3.2.1: The "atom:name" element's content conveys a human-readable name for the person. The content of atom:name is Language-Sensitive. Person constructs MUST contain exactly one "atom:name" element. http://tools.ietf.org/html/rfc4287#section-6.3: Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error. So, the following is legal already, according to RFC 4287: foo And, I can't find anything that disallows the "type" attribute either: foo Keep in mind that the Relax NG schema in RFC 4287 is non-normative, and Appendix B already admits that the schema is too restrictive. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 01:00:10 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBl1u-0002VR-UJ for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 01:00:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBl1u-0006vR-Dq for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 01:00:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m075WmgL035310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jan 2008 22:32:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m075WmbL035309; Sun, 6 Jan 2008 22:32:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m075Wl3Y035303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Jan 2008 22:32:48 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 5654723E496 for ; Mon, 7 Jan 2008 00:32:47 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> <47817700.4030706@gmail.com> <87wsqmwexc.fsf_-_@djpowell.net> <4781942F.1010806@gmail.com> Subject: RE: Bidi Date: Sun, 6 Jan 2008 23:36:41 -0800 Message-ID: <000201c85100$0c83c030$0701a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchQ2N66gjHGckD2SaKW2IJdGUWYFAAJUT0g In-Reply-To: <4781942F.1010806@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 James M Snell wrote: > David Powell wrote: > > Constructive criticism now - could you explain this: > > > > Implementers are reminded that unexpected results could occur when > > using both the "dir" attribute and the Unicode control characters > > within a single document. > > > > Isn't using both the expected, and only, way to mark-up > > bidi text when the Unicode heuristics won't do a good enough job? > > It seems a bit odd to warn against using the feature as intended? > > No, both should not be used. > > >> Third, neither Unicode or the W3C recommend using the Unicode bidi > >> formatting codes are not recommended in markup, for a variety of > >> reasons. > > > > True, but I'm not sure I'd describe a plain text element content or > > attribute value as markup. Isn't markup something that could > > alternatively contain tags, and be "marked-up"? Given that these > > locations can't, the Unicode bidi codes will need to be used > > regardless, so I'm not sure whether those recommendations > apply here? > > > > The markup in question here are the Atom elements. In other > words, the bidi formatting characters should not be used in > XML, period, not just within specific kinds of elements. > Even the W3C recommends Unicode control characters in some situations; see [1]. I don't know why those W3C guidelines regarding markup vs. formatting codes are different from [2], but the use of Unicode bidi formatting characters in Atom is also reinforced by the language in [3]: "Other situations where control characters may provide the only resort are elements that only allow character content or that omit support for directional attributes." IMO, that is exactly the case that Atom fits into, since RFC4287 has no BIDI features built in. [1] Internationalization Best Practices: Handling Right-to-left Scripts in XHTML and HTML Content http://www.w3.org/TR/i18n-html-tech-bidi/#ri20030218.135304584 [2] Unicode in XML and other Markup Languages http://www.w3.org/TR/unicode-xml/ [3] FAQ: Unicode controls vs. markup for bidi support http://www.w3.org/International/questions/qa-bidi-controls.en.php#proble ms - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 02:59:47 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmtf-0002gZ-4q for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 02:59:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBmtc-0000OZ-MQ for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 02:59:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m077jaRh042267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 00:45:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m077ja7l042266; Mon, 7 Jan 2008 00:45:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m077jZU8042255 for ; Mon, 7 Jan 2008 00:45:36 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1383189anc.44 for ; Sun, 06 Jan 2008 23:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Pw80vxOihcbB30uTGxEhjpUGsKI/aJ+T1gVebwgv2wg=; b=GQBLdoElrCVHzs+Ms2eQhPHQORY7bozEiTPGT3CgFXXOWM+lNX7vkbKTTHSK5HxlxhoyG84XJSzsrAE4KOQnxj1eJOPQd/24JzD5DnRAMB9iT5bi8Bf8g8ORGbnI0JlYEaSmcsJ7QNbRPDLsmkUQuKezyWH2KFJgEL2duZHyZa0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=L/Vjsi9C3PMofMlzkxPMxfZ1vN6ULKQPjymWO/go4BQPbuIfNWPQrcuGT6hy+Ei9udxaxEP/kl/WNq2h19O0MuzpO22InvDNEK4Wj52NGvlewdHnGZMvmVbS9P3coKCruSt3KFuhJIwiOGildmbQs+WSGGpAo+w4sYljCL/ZBpQ= Received: by 10.100.247.14 with SMTP id u14mr40144934anh.79.1199691935035; Sun, 06 Jan 2008 23:45:35 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a45sm4161085rne.10.2008.01.06.23.45.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 23:45:34 -0800 (PST) Message-ID: <4781D89B.3080301@gmail.com> Date: Sun, 06 Jan 2008 23:45:31 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: BIDI (was Proposal: Atomext WG) References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> In-Reply-To: <000101c850fe$b7d16d90$0701a8c0@T60> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Brian Smith wrote: > [snip] >>> Atom documents are almost never hand-entered, and there is >>> already a specification in place for markup up BIDI and even >>> ruby text in general XML. The odds that clients and servers >>> are going to correctly implement this extension--except >>> those targeted direclty towards BIDI users--seem pretty >>> low to me. Personally, it seems much easier to >>> implement the an existing BIDI markup mechanism (Unicode, >>> XML, and/or XHTML) than a new standard. >> What are you basing that on? > > The Unicode/W3C guidelines (http://www.w3.org/TR/unicode-xml/#Bidi and http://www.w3.org/International/questions/qa-bidi-controls) say this: > > * Use *XHTML* BIDI markup whenever possible. > * Otherwise *CSS* whenever possible. > * Otherwise, consider building BIDI markup into your markup schema. > * We have to support BIDI formatting codes anyway, since the above mechanisms don't solve all BIDI problems. > Sorry if I wasn't clear, I was referring specifically to your assertion that, "it seems much easier to implement the an existing BIDI markup mechanism"... Having already implemented it, I can see no additional complexity or difficulty. >> There's really not much guess work >> involved in the implementation and apps that choose not to implement >> support will be no worse or better off than they are currently. > > That is not true. Consider a feed aggregator. If it doesn't support > Atom BIDI, then it will not correctly rewrite entries to handle an > inherited "dir" attribute from the atom:feed element. Since the > directionality is also inherited by text constructs, whenever the > implementation passes the text construct to a rendering engine, it > needs to rewrite that content to handle the inherited directionality. If an aggregator doesn't support the dir attribute, it will ignore it or drop it as if it wasn't there in the first place and will continue to operate as it always had, which is exactly what we want. So again, those apps will be no worse or better off than they are currently. > >> Don't forget atom:link/@title and atom:category/@label. >> atom:category/@term can also cause problems when >> implementation use that >> value for display purposes. > > I know that. But, the Atom BIDI draft does not eliminate all uses of BIDI > formatting characters in these attributes, either. And, it doesn't specify > BIDI support for language-sensitive content in Atom service documents, > category documents, RSS feeds, or RSD documents. I have no interest in eliminating all uses of bidi formatting characters. And yes, the spec does address bidi support for language-sensitive content in Atompub service and category documents. The spec language can be improved in this regard, but the spec alters the definition of the atomCommonAttributes production to add the dir attribute. In both the Atompub service document and the Atom categories document, the langauge-sensitive text is provided by elements from the Atom namespace (e.g. atom:category and atom:title). Also, the bidi spec predates the publication of rfc5023; I intend to have the next rev of the spec specifically discuss atompub service docs. As for RSS and RSD doc's, I couldn't care less about solving the i18n issues of either. > >> Arbitrary extension elements can also have problems. > > The BIDI draft says it only applies to constructs that RFC4287 labeled "language sensitive." Accordingly, the BIDI draft does not apply to extension elements. > Section 6.4.2: "Structured Extension elements are Language-Sensitive." >> The bidi draft doesn't attempt to solve all the i18n issues >> with Atom. Ruby text is a problem for pretty much everything, >> especially given the fact that most browsers don't have a >> clue how to properly render ruby text yet. The bidi draft >> rightfully focuses on one small part of the problem. > > I agree that a narrow scope is good. But, a solution for Ruby text will also be applicable to BIDI, especially if that solution involves the reuse of XHTML markup and/or CSS. > if/when the need emerges to improve ruby text support in Atom, I will glady help work out a solution. >>> It also doesn't solve the problem with atom:link/@title or >> other attributes that >>> are language-sensitive. >> Yes, it does. > > The Atom BIDI draft does not provide a way of specifying base different > base directionalities for attributes on the same element, it doesn't eliminate > all need for BIDI formatting characters in language-sensitive attribute values, > it doesn't provide a mechanism for discovering which (nested) extension elements > and attributes are affected by the proposed Atom BIDI markup. atom:category and atom:link each have exactly one language-sensitive attribute. there's no reason to try eliminating all need for bidi formatting characters in language sensitive attribute values. The bidi attribute applies to language-sensitive elements and attributes. Defining which extension elements are language sensitive is up to the extension definition. There's no reason to provide a mechanism for discovering which extensions are affected. > > If I implement RFC4287, the Unicode BIDI algorithm, XHTML BIDI, HTML BIDI, and > the "Unicode in XML" guidelines, I will have pretty good BIDI support. It will > require me to adhere to four different BIDI standards in addition to RFC4287. > That is a lot of work already. Now, your Atom BIDI and URI template BIDI proposals > add two more specifications that I would have to support--for a total of SIX standards > to adhere to and resolve conflicts between, JUST to support BIDI text. And, even if > I create well-formed documents adhering to all six standards, whenever I open them up > in any of my text editors, or any feed reader, they will look wrong since nobody > else is implementing all of those standards. I think that is totally unreasonable. > Abdera might have amazing support for BIDI, for which you should be commended, but > unless all Atom software is going to be implemented on top of Abdera, Abdera will > not be able to reliably interoperate with anything. If we want to provide interopera! > ble support for BIDI, we need to make it as simple to implement as possible. > > My counter-proposal is simple: > None of this is simple. Please do not claim that it is. > * Use XHTML/HTML BIDI/Ruby markup whenever possible. Keep in mind the fact that the atom bidi spec very clearly indicates that the (x)html bidi mechanisms should be used in addition to the atom dir attribute. > * Otherwise, use Unicode BIDI/Ruby formatting codes, such that matching pairs of formatting codes are fully contained within a single text or attribute node. Whose responsibility is it to apply the formatting codes? The person typing the text or the software? How does the software know when to apply the codes? Also, what about when an Atompub client edits an entry? Is the Atompub client responsible for preserving the unicode formatting characters? What if they don't? There are existing Atompub clients out there that, more than likely, will not, and since the formatting codes are non-visual, it's not likely the user will notice them either, causing unexpected rendering issues later on. How are non-bidi enabled clients supposed to know what to do? With the bidi attribute approach, per rfc5023, non-supporting clients are expected to at least preserve the bidi attribute but will otherwise continue working as they currently do, without risk of corrupting the text by inadvertently dropping or improperly nesting the bidi controls. Also, imagine a case where we have a feed with 100 entries, each with about 5 atom:category elements. Let's stay that the feed is generally all RTL. Using your approach, that's at least 1000 extra characters in the feed, and 500 opportunities for the embedding to be screwed up. Re: The ruby formatting codes: Even the Unicode spec warns against using the ruby formatting codes for anything other than internal storage. We gain absolutely nothing by bringing ruby into this discussion. > * Editors of new documents must be meticulous about inserting the proper markup and formatting codes. > * Processors of existing documents must be meticulous about preserving BIDI/Ruby markup and/or formatting codes whenever any part of the contained text is preserved. > Again, what about older editors that know nothing about the proper markup or formatting codes? > I recognize that this goes against the Unicode in XML guidelines. However, Atom > already goes against the guidelines by having language-sensitive text in attribute > values and other contexts where XHTML markup cannot be used. > What is the benefit of going against the Unicode in XML guidelines? - James > - Brian > > > From owner-atom-syntax@mail.imc.org Mon Jan 07 03:09:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBn39-0006JF-O5 for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 03:09:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBn39-0000VL-4O for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 03:09:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m077uu12043372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 00:56:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m077uu4O043371; Mon, 7 Jan 2008 00:56:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m077utN9043365 for ; Mon, 7 Jan 2008 00:56:56 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1383742anc.44 for ; Sun, 06 Jan 2008 23:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=M+Hf69rDDosL4kahEc3iaZkZo2rFavQTZTKBD4jxPkA=; b=eN0ZNYl66/O/y8Rxe0LsULfqufZI4fA5Wsg2RduQa9sDSvcTpl70UiTTC7QeY6dmDqp9FZ4PLk8bu2urGDI9zZ0L//rN70LA8Cqq9Bzct7KaPZ4L3a3hmrpXsPlcqgxubO3HaS9yOq0TQ+Nub1YNcEjgqhpyNSogQ96aq6Iw4No= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=DgWIeBC5yNrQJ7TVQxufukIAP4xqWBGmKS01Um9iJGwxFGGPeX9fdPf0AWRcSl0kGFsIIGEyNqqVFhfGp3BSZNlQhPqdmr06+7/DnGIvWJ+8ZQQkRjnCBuGGcRyV6TPk+8C5MO3T9CRpoSHexU5v/LNXKoRBa3uKmieJlyAmM+8= Received: by 10.100.227.20 with SMTP id z20mr34517539ang.106.1199692615456; Sun, 06 Jan 2008 23:56:55 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a30sm4143804rnb.16.2008.01.06.23.56.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jan 2008 23:56:55 -0800 (PST) Message-ID: <4781DB44.7040101@gmail.com> Date: Sun, 06 Jan 2008 23:56:52 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: Markup in atom:name (was RE: Proposal: Atomext WG) References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> <000001c850fe$b763deb0$0701a8c0@T60> In-Reply-To: <000001c850fe$b763deb0$0701a8c0@T60> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 With this, I think it is important to look at both the original intent of the spec and what clients are most likely to support. While the schema is non-normative, the fact that atom:name is clearly and specifically marked as "text" in the schema makes the intent clear. You *might* be able to stretch really far and claim that escaped HTML is permitted, but if that was the intent, the spec would more than likely say so. If you want the Person construct to contain ruby text, the best approach would be to define an extension element designed for the purpose of providing a "display" version of the name, e.g. name name(ruby) ... This would allow existing clients to continue to operate as they always have. - James Brian Smith wrote: > David Powell wrote: >> Brian Smith wrote: >> If we really need support for Ruby and bidi in , >> and we aren't immediately intending to supercede RFC4287, I >> think we would be better adding an additional entry/person >> metadata element that supports HTML names. But to be honest, >> I'd like to see people knocking on our doors before we start >> writing drafts to solve potential problems. > > I have Japanese users and Japanese language learners that make extensive use of Ruby markup as an instructional device for teaching Kanji (the complex Japanese characters). > > http://tools.ietf.org/html/rfc4287#section-6.4: Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden. > > http://tools.ietf.org/html/rfc4287#section-3.2.1: The "atom:name" element's content conveys a human-readable name for the person. The content of atom:name is Language-Sensitive. Person constructs MUST contain exactly one "atom:name" element. > > http://tools.ietf.org/html/rfc4287#section-6.3: Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error. > > So, the following is legal already, according to RFC 4287: > > xmlns:html='http://www.w3.org/1999/xhtml'> > > foo > > > > And, I can't find anything that disallows the "type" attribute either: > > xmlns:html='http://www.w3.org/1999/xhtml'> > > foo > > > > Keep in mind that the Relax NG schema in RFC 4287 is non-normative, and Appendix B already admits that the schema is too restrictive. > > - Brian > > > From owner-atom-syntax@mail.imc.org Mon Jan 07 05:00:29 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBomT-0002SH-Oy for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 05:00:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBomS-0001wq-10 for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 05:00:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m079gTNB049601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 02:42:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m079gTM8049600; Mon, 7 Jan 2008 02:42:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from joe.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m079gPb6049590 for ; Mon, 7 Jan 2008 02:42:26 -0700 (MST) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.6] (unknown [192.168.1.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 5E95CE19EF; Mon, 7 Jan 2008 10:42:24 +0100 (CET) In-Reply-To: References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> <47817683.9090300@dehora.net> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0B3F3206-6FF8-4824-ABD4-850A8B240E39@greenbytes.de> Cc: Bill de hOra , atom-syntax From: Stefan Eissing Subject: Re: Updated Tombstones Draft Date: Mon, 7 Jan 2008 10:42:22 +0100 To: Mark Nottingham X-Mailer: Apple Mail (2.753) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m079gQb6049593 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m079gTNB049601 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 What really can pollute a namespace are implementations of drafts =20 that never made it to RFC. If atom namespace is used for experimental =20 extensions, we are in danger of ending up with implementations "out =20 there" that misinterpret what the final RFC will say. *) So, I think it is wise to publish all extensions in an own namespace =20 and switch that to atom (if desired) when the RFC gets final. James =20 proposal of a WG (or this mailing list for all practical purposes), =20 should then decide what to migrate to atom namespace and what not, so =20 that the terminology inside atom remains consistent and good to =20 understand. //Stefan *) Given the time periods necessary for pushing a spec to RFC, this =20 is more likely than not. If you really need a feature in your =20 product, you will ship implementations based on pre-drafts. And later =20 on you need to talk to these implementations... (Just catching up on mail after vacation, so please excuse if I have =20 overreaad something.) Am 07.01.2008 um 02:11 schrieb Mark Nottingham: > > > On 07/01/2008, at 11:46 AM, Bill de hOra wrote: > >> >> Mark Nottingham wrote: >>> The sentence afterwards is a bit more revealing; >>>> The Atom namespace is reserved for future forward-compatible =20 >>>> revisions of Atom. Future versions of this specification could =20 >>>> add new elements and attributes to the Atom markup vocabulary >>> There are two ways to read this; >>> 1) Future RFCs that completely replace RFC4287 are the only ones =20 >>> allowed to add new elements and attributes. >>> 2) Future RFCs that update RFC4287 are allowed to add new =20 >>> elements and attributes. >>> Given that we allow pretty much anybody to rock up and add a link =20 >>> relation with IESG approval, it doesn't seem like a far stretch =20 >>> to me to say that #2 is the right reading, given that the only =20 >>> real difference between the two is regarding document structure =20 >>> (i.e., the whole doc + extension, or just extension). >>> In other words, by the logic of #1, the only thing James would =20 >>> have to do is to copy RFC4287, add a section on tombstones, and =20 >>> push it through the process. That seems pointlessly tortured, to =20 >>> say the least. >>> I think the most you could say is that #2 needs IESG approval via =20 >>> a standards-track RFC (again, notice the parity with the link =20 >>> relation registry), but that's already assumed in the discussions =20 >>> I've seen here. >>> But that's just my .02. >> >> If there's a good technical or social reason to put tombstones =20 >> into the atom namespace, let's hear it. > > As I think I said before, it's not a big deal either way; I just =20 > don't want people to walk away thinking that *no* extension can be =20 > in the atom namespace. Whether or not Tombstones in particular =20 > belong in the Atom namespace is mostly a question of how common we =20 > think they'll be once deployed, across a variety of use cases. > > Personally, I think that there's potential for them to be widely =20 > deployed across a number of use cases. In a way, both tombstones =20 > and feed history feel like 'missing' parts of atom (but I realise =20 > that from some perspectives, that can be said of almost any =20 > extension). > > Cheers, > > > > -- > Mark Nottingham http://www.mnot.net/ > -- bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany Amtsgericht M=FCnster: HRB5782 From owner-atom-syntax@mail.imc.org Mon Jan 07 10:23:07 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBtoh-0002Id-4B for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 10:23:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBtoe-0007us-RE for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 10:23:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07F9T04071071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 08:09:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07F9TUj071070; Mon, 7 Jan 2008 08:09:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07F9Rfo071060 for ; Mon, 7 Jan 2008 08:09:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so5179240rvf.34 for ; Mon, 07 Jan 2008 07:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=FX5+lq/hd1OhlHTf7IbQclYAw8DlzlDJvJod+Ws1ip0=; b=mFnmskEorobzHdLWXCvDPa1vGXoEuRudyweYdTn+9G8MWoexDK67cik0O6OuJDWlhg+DM9Sbf/aR5CZ3SAUmTuF+KE1CrRvrf7OUnR/omJZcqn3JTc8djGAqJ4FGCFlN4DXyd3+KLbI1crrpsxBg6w0bsROOwmRcLZR0mwQXYG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=lqz7xMEBFJa4CDc3a2w60Vnphuk9okITvJFnUjJCEcPvf9A6ZQjYQCL+JKhUSQBsTTyGK5ZqLCtctIYop189FIiSnX6EPLFObLY7F1qxSnaoRlJ0UMXQYYwE5/fgdoz2++y6ZZlaUqUYaOBbhy5wY/lsR89g2LRcmDOz+gsesBQ= Received: by 10.141.75.6 with SMTP id c6mr4546311rvl.43.1199718566963; Mon, 07 Jan 2008 07:09:26 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id g22sm859723rvb.5.2008.01.07.07.09.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jan 2008 07:09:26 -0800 (PST) Message-ID: <478240A4.3020601@gmail.com> Date: Mon, 07 Jan 2008 07:09:24 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Eissing CC: Mark Nottingham , Bill de hOra , atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> <47817683.9090300@dehora.net> <0B3F3206-6FF8-4824-ABD4-850A8B240E39@greenbytes.de> In-Reply-To: <0B3F3206-6FF8-4824-ABD4-850A8B240E39@greenbytes.de> X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 So long as the process for how an extension becomes part of the core namespace is clear and unambiguous, this is perfectly fine. - James Stefan Eissing wrote: > [snip] > So, I think it is wise to publish all extensions in an own namespace and > switch that to atom (if desired) when the RFC gets final. James proposal > of a WG (or this mailing list for all practical purposes), should then > decide what to migrate to atom namespace and what not, so that the > terminology inside atom remains consistent and good to understand. > > //Stefan > [snip] From owner-atom-syntax@mail.imc.org Mon Jan 07 10:59:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuO8-0007J3-4U for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 10:59:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBuO7-00004r-Nf for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 10:59:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07FkDk8074013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 08:46:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07FkDsP074012; Mon, 7 Jan 2008 08:46:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07FkDdJ074006 for ; Mon, 7 Jan 2008 08:46:13 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 8A68ADDC4F for ; Mon, 7 Jan 2008 15:46:12 +0000 (UTC) Message-ID: <47824941.4020207@dehora.net> Date: Mon, 07 Jan 2008 15:46:09 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> <47817683.9090300@dehora.net> <478178D6.8000301@gmail.com> In-Reply-To: <478178D6.8000301@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 They would be whatever the IETF agreed them to be. But I'm not sure this is fruitful - trying to predict criteria to add markup to the Atom namespace in advance of the markup existing isn't the same as evaluating specific markup. I can imagine a situation where no new markup needs to be added to the Atom ns, exactly because of Atom's extension model doesn't require any processor to understand it. That's not the same as saying it's entirely arbitrary, nor is it arguing that nothing should ever be added to the ns. cheers Bill James M Snell wrote: > Let's forget about the tombstone draft for a minute. If there are good > technical and social reasons to add any elements or attributes to the > Atom namespace, what would they be? > > - James > > Bill de hOra wrote: >> [snip] >> >> If there's a good technical or social reason to put tombstones into >> the atom namespace, let's hear it. >> >> cheers >> Bill >> >> From owner-atom-syntax@mail.imc.org Mon Jan 07 11:09:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuXq-00035a-Ei for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 11:09:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBuXo-0000GD-Vq for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 11:09:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07FWxeG073010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 08:32:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07FWxcB073009; Mon, 7 Jan 2008 08:32:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07FWwED073003 for ; Mon, 7 Jan 2008 08:32:59 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227]) by chilco.textdrive.com (Postfix) with ESMTP id 2C51EDE70F for ; Mon, 7 Jan 2008 15:32:57 +0000 (UTC) Message-ID: <47824627.7040906@dehora.net> Date: Mon, 07 Jan 2008 15:32:55 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: atom-syntax Subject: Re: Updated Tombstones Draft References: <477C4554.3090407@gmail.com> <477C65AB.9000302@dehora.net> <3D17D96C-3D53-418E-ABF0-C9430000A11D@mnot.net> <477D2328.80609@dehora.net> <1EED15B1-54AD-4F8E-A690-2714E1563501@mnot.net> <47817683.9090300@dehora.net> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Mark Nottingham wrote: > As I think I said before, it's not a big deal either way; I just don't > want people to walk away thinking that *no* extension can be in the atom > namespace. Completely understand; that's not my intention. Btw, there's a 3rd way to read the extensibility text - any RFC that adds names to the Atom namespace automatically updates RFC4287. cheers Bill From owner-atom-syntax@mail.imc.org Mon Jan 07 11:39:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBv0m-0001tR-MH for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 11:39:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBv0l-0000os-1x for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 11:39:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07GNqkX076437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 09:23:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07GNqnB076436; Mon, 7 Jan 2008 09:23:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07GNnoY076429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jan 2008 09:23:51 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id EE03523E3E8 for ; Mon, 7 Jan 2008 11:23:47 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Mon, 7 Jan 2008 10:27:43 -0800 Message-ID: <000101c8515a$fec4dc80$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4781D89B.3080301@gmail.com> Thread-Index: AchRAegMlYQd7KojQ3STfBAil1+bYAATFlog X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07GNpoX076431 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 James M Snell wrote: > Brian Smith wrote: > > The Unicode/W3C guidelines say: > > * Use *XHTML* BIDI markup whenever possible. > > * Otherwise *CSS* whenever possible. > > * Otherwise, consider building BIDI markup into your markup schema. > > * We have to support BIDI formatting codes anyway, since > > the above mechanisms don't solve all BIDI problems. > > Sorry if I wasn't clear, I was referring specifically to your > assertion that, "it seems much easier to implement the an > existing BIDI markup mechanism"... Having already implemented > it, I can see no additional complexity or difficulty. I wrote an Atom-to-HTML converter in XSLT, where, as long as the BIDI formatting characters do not span (text/attribute) nodes in the document, the BIDI directionality is maintained. This is trivial to do by simply preserving the values of the nodes. In fact, many applications should *accidently* get it right as long as they are not doing rewriting of the actual content of the nodes; even then, they will still probably get it right. This is the primary basis of my assertion: significantly more BIDI-oblivious applications will preserve Unicode formatting characters than BIDI markup. > > The BIDI draft says it only applies to constructs that > > RFC4287 labeled "language sensitive." Accordingly, the BIDI > > draft does not apply to extension elements. > > Section 6.4.2: "Structured Extension elements are Language-Sensitive." > > atom:category and atom:link each have exactly one language-sensitive > attribute. Which attributes on elements and subelements of structured extension elements are language-sensitive? It seems it must be either all or none. > there's no reason to try eliminating all need for bidi formatting > characters in language sensitive attribute values. I agree. If there are going to be formatting codes in the document anyway, then why do we need a mechanism that duplicates their functionality? > > * Otherwise, use Unicode BIDI/Ruby formatting codes, such > that matching pairs of formatting codes are fully contained > within a single text or attribute node. > > Whose responsibility is it to apply the formatting codes? The person > typing the text or the software? How does the software know when to > apply the codes? > Also, what about when an Atompub client edits an entry? > Is the Atompub client responsible for preserving the unicode > formatting characters? What if they don't? My hypothesis is that an implementation ignorant of BIDI issues is more likely to preserve the formatting characters than Atom/XHTML/HTML BIDI markup, especially when the effects of those formatting characters never span multiple nodes in the document. > There are existing Atompub clients out there that, more than likely, > will not, and since the formatting codes are non-visual, it's not > likely the user will notice them either, causing unexpected > rendering issues later on. I don't understand why a user that needs BIDI functionality would use a client that doesn't have BIDI support. Further, I don't understand how clients that are incapable of generating BIDI formatting codes can generate markup compliant with your proposal. Are you expecting the users to edit the markup directly? Markup is just as non-visual as formatting codes, except for people using "view source" and the like. > With the bidi attribute approach, per rfc5023, non-supporting > clients are expected to at least preserve the bidi attribute > but will otherwise continue working as they currently do, > without risk of corrupting the text by inadvertently dropping > or improperly nesting the bidi controls. RFC 4287 and RFC 5023 is pretty unclear about what is required to be preserved. Firstly, RFC 5023 says that implementations can do whatever they want as long as the results are well-formed. Otherwise, AtomPub implementations that use (X)HTML whitelists would be non-compliant. Also, the requirement to preserve unknown foreign markup seems to apply more to unknown extension elements than to unknown attributes on known elements. In particular, if I replace the atom:author element with a new one, then I am not going to preserve the old, unknown attributes on the previous atom:author element. > Also, imagine a case where we have a feed with 100 entries, each with > about 5 atom:category elements. Let's stay that the feed is > generally all RTL. Using your approach, that's at least 1000 extra > characters in the feed, and 500 opportunities for the embedding to > be screwed up. The category labels are almost always going to be composed of strong RTL and strong LTR characters (only), so the BIDI algorithm will work correctly. And, when it doesn't work, it is unlikely that it will be due to the wrong base directionality--in these cases, formatting characters are going to be needed no matter what. Right? > Re: The ruby formatting codes: Even the Unicode spec warns > against using the ruby formatting codes for anything other than internal > storage. We gain absolutely nothing by bringing ruby into this discussion. I disagree. Bringing Ruby text into the discussion emphasizes the need for *new* language-sensitive constructs to be text constructs, and emphasizes the need to support (X)HTML in all text constructs instead of depending on Unicode formatting codes. > > * Editors of new documents must be meticulous about > > inserting the proper markup and formatting codes. > > * Processors of existing documents must be meticulous about > > preserving BIDI/Ruby markup and/or formatting codes whenever > > any part of the contained text is preserved. > > Again, what about older editors that know nothing about the proper > markup or formatting codes? All of these old editors will also fail to implement the Atom BIDI spec too. There are currently more editors that can insert formatting characters than can handle Atom BIDI markup, aren't there? I think that will always be the case. > > I recognize that this goes against the Unicode in XML > > guidelines. However, Atom > > already goes against the guidelines by having > > language-sensitive text in attribute > > values and other contexts where XHTML markup cannot be used. > > What is the benefit of going against the Unicode in XML guidelines? 1. It is extremely easy to implement. As long as an implementation copies text nodes and attribute node values verbatim, or using any transform that doesn't strip out formatting codes, the BIDI directionality will always be preserved, with no extra work. A processor can extract any entry, the content of any entry, any entry metadata, or any feed metadata, without having to rewrite the markup to preserve the BIDI information. Literally, it requires more work to screw it up than it is to implement it correctly. 2. It is general purpose. It works for RSS, Atom, and any other XML format. 3. It reuses existing markup without introducing any of its own. Here is an expanded version of my proposal that provides BIDI and Ruby support for all language-sensitive constructs in Atom:. In all cases, only use markup and/or formatting codes when necessary. It is recommended to avoid Ruby Unicode formatting characters whenever possible. Text Constructs: Use (X)HTML, and use the (X)HTML BIDI and Ruby markup. atom:content: Use (X)HTML whenever possible. For other XML content, use the existing BIDI and Ruby markup defined for that XML application; Otherwise, use Unicode formatting codes, and ensure that matching pairs of formatting codes do not span multiple text nodes. For cases where type="text" must be used, use Unicode formatting characters. Language-sensitive attributes: Use Unicode formatting characters. Extension elements: New language-sensitive extension elements should ensure that all language-sensitive text is enclosed in text constructs. In particular, do not use attributes for language-sensitive text, support at least type="xhtml", and support type="html" whenever possible. Be sure to support BIDI and Ruby markup. atom:name: When consuming atom:name, treat it as though it was defined as a text construct, and allow for type="xhtml" and type="html". When producing atom:name elements, BIDI markup SHOULD be replaced with Unicode formatting characters when needed. Ruby markup may be replaced with Unicode formatting characters or stripped entirely. All markup should be stripped entirely, the type attribute should be removed. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 12:57:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBwE6-0002nX-Oj for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 12:57:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBwE4-0004FU-Lo for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 12:57:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07HY1tw082947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 10:34:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07HY1J0082946; Mon, 7 Jan 2008 10:34:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07HXw4c082936 for ; Mon, 7 Jan 2008 10:33:59 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1422386anc.44 for ; Mon, 07 Jan 2008 09:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=tyuGeZdr0BSME+5idAXRHr2BYEKTvjPB8B31Hp54Ngo=; b=UCbeMh+Nf7UchPPXV+n3jKmj4EB4rRCkICWQpcPT06LVaDXtS/xvrWBO4Z8yaEs9VggV2zLLR5hG8gqq+2wQHCb//f6fVu3dvwoueila39mlPhNOWzlB8rzFIcSH5hzgCsw5KrpjetIwsVJhd60LahVKfq2EXJ6udZAwnA9cBGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=XS/EvSfL/RLJ2iFCfAmrZSWB2gUpJooowI4rJtruVk/9YcDyFFPvN4qJwq44OGdpwVd8HGE+5rRnHudcQ6GyAGMmRwIRkdwCycUcBKV3+4U/K/j1s607KgfvC9+8honQ2b30uCA7GTLJbJq5o1siv/2h863DE8zHEPemEB/KYaI= Received: by 10.100.255.10 with SMTP id c10mr43057233ani.54.1199727238618; Mon, 07 Jan 2008 09:33:58 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id s40sm13610764hsb.5.2008.01.07.09.33.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jan 2008 09:33:54 -0800 (PST) Message-ID: <4782627F.8060001@gmail.com> Date: Mon, 07 Jan 2008 09:33:51 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: BIDI (was Proposal: Atomext WG) References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> In-Reply-To: <000101c8515a$fec4dc80$2401a8c0@T60> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Brian Smith wrote: > [snip[ >>> The BIDI draft says it only applies to constructs that >>> RFC4287 labeled "language sensitive." Accordingly, the BIDI >>> draft does not apply to extension elements. >> Section 6.4.2: "Structured Extension elements are Language-Sensitive." >> >> atom:category and atom:link each have exactly one language-sensitive >> attribute. > > Which attributes on elements and subelements of structured extension elements are language-sensitive? It seems it must be either all or none. > It depends on the definition of the extension. If you're not familiar with the extension, you have no way of knowing. >> there's no reason to try eliminating all need for bidi formatting >> characters in language sensitive attribute values. > > I agree. If there are going to be formatting codes in the document anyway, then why do we need a mechanism that duplicates their functionality? > Because their use in markup is problematic and is actively discouraged for a number of very good reasons. >>> * Otherwise, use Unicode BIDI/Ruby formatting codes, such >> that matching pairs of formatting codes are fully contained >> within a single text or attribute node. >> >> Whose responsibility is it to apply the formatting codes? The person >> typing the text or the software? How does the software know when to >> apply the codes? > >> Also, what about when an Atompub client edits an entry? >> Is the Atompub client responsible for preserving the unicode >> formatting characters? What if they don't? > > My hypothesis is that an implementation ignorant of BIDI issues is more > likely to preserve the formatting characters than Atom/XHTML/HTML BIDI > markup, especially when the effects of those formatting characters never > span multiple nodes in the document. Have you tested this hypothesis using real editors? Example, in our internal blogging environment, tags are entered in a single text box, each tag separated by a comma. The system splits the tags into an array and saves each tag separately. Each tag becomes a separate atom:category element. Is the user responsible for adding the appropriate formatting codes around each individual tag? When the user wishes to edit the entry later, perhaps to add a new entry, are they supposed to just know that there are non-visual bidi formatting codes interspersed into the comma separated list of tags? > >> There are existing Atompub clients out there that, more than likely, >> will not, and since the formatting codes are non-visual, it's not >> likely the user will notice them either, causing unexpected >> rendering issues later on. > > I don't understand why a user that needs BIDI functionality would use a > client that doesn't have BIDI support. Further, I don't understand how > clients that are incapable of generating BIDI formatting codes can generate > markup compliant with your proposal. Are you expecting the users to edit > the markup directly? You're assuming that all users have the same requirements. In our environment, a single feed may include entries from many different users. We have group blogs where users from many different locales have edit rights on any entry in the blog. Further, our users use many different editors to write and manage their blog entries. Asking those users to be mindful of how they're using bidi formatting characters is a lot more difficult than what we currently do, which is provide a simple check box to indicate whether or not the entry is "right-to-left", which in turn, is translated into the appropriate dir="rtl" in the markup. Clients that do not understand the dir attribute simply ignore it, and since our software is written so that only explicit changes in value are recognized (e.g. a missing dir attribute does not mean the dir attribute value has changed) we're able to work seamlessly with editors that do not support the attribute. > > Markup is just as non-visual as formatting codes, except for people using "view source" and the like. > Yes, but with the marup we don't have to rely on users getting it right when they type in the values. >> With the bidi attribute approach, per rfc5023, non-supporting >> clients are expected to at least preserve the bidi attribute >> but will otherwise continue working as they currently do, >> without risk of corrupting the text by inadvertently dropping >> or improperly nesting the bidi controls. > > RFC 4287 and RFC 5023 is pretty unclear about what is required to be preserved. RFC 5023, Section 9.3: To avoid unintentional loss of data when editing Member Entries or Media Link Entries, an Atom Protocol client SHOULD preserve all metadata that has not been intentionally modified, including unknown foreign markup as defined in Section 6 of [RFC4287]. Seems pretty darn clear to me. > Firstly, RFC 5023 says that implementations can do whatever they want as long as > the results are well-formed. Otherwise, AtomPub implementations that use (X)HTML > whitelists would be non-compliant. Also, the requirement to preserve unknown foreign > markup seems to apply more to unknown extension elements than to unknown attributes > on known elements. In particular, if I replace the atom:author element with a new > one, then I am not going to preserve the old, unknown attributes on the previous > atom:author element. > 9.3 uses the term "unknown foreign markup", which, if RFC 4287 defines as unknown elements AND attributes. >> Also, imagine a case where we have a feed with 100 entries, each with >> about 5 atom:category elements. Let's stay that the feed is >> generally all RTL. Using your approach, that's at least 1000 extra >> characters in the feed, and 500 opportunities for the embedding to >> be screwed up. > > The category labels are almost always going to be composed of strong RTL and > strong LTR characters (only), so the BIDI algorithm will work correctly. And, > when it doesn't work, it is unlikely that it will be due to the wrong base > directionality--in these cases, formatting characters are going to be needed > no matter what. Right? "almost always" is not "always". The Atom bidi draft covers the cases where "always" is more desirable than "almost always". And no, the formatting characters are not always going to be needed. If I am rendering the text in (x)html, I don't want the formatting characters in there at all; rather, I want to follow best practices and use the (x)html provided bidi markup mechanisms. > [snip] >>> * Editors of new documents must be meticulous about >>> inserting the proper markup and formatting codes. >>> * Processors of existing documents must be meticulous about >>> preserving BIDI/Ruby markup and/or formatting codes whenever >>> any part of the contained text is preserved. >> Again, what about older editors that know nothing about the proper >> markup or formatting codes? > > All of these old editors will also fail to implement the Atom BIDI spec too. > There are currently more editors that can insert formatting characters than > can handle Atom BIDI markup, aren't there? I think that will always be the case. > Failing to implement the atom bidi spec has significantly fewer consequences than improperly implementing the unicode formatting characters. That is, existing applications will be no worse off than they currently are if the dir attribute is ignored or dropped; however, existing applications can be severely impacted by the improper use of the unicode bidi characters. Again, there are very good reasons behind the recommendation against using the formatting codes in markup. > [snip] > atom:name: When consuming atom:name, treat it as though it > was defined as a text construct, and allow for type="xhtml" > and type="html". When producing atom:name elements, BIDI markup > SHOULD be replaced with Unicode formatting characters when needed. > Ruby markup may be replaced with Unicode formatting characters or > stripped entirely. All markup should be stripped entirely, the > type attribute should be removed. > As I pointed out in my previous note, this is not an interoperable suggestion and is not supported in any way by the specification. - James > - Brian > > > From owner-atom-syntax@mail.imc.org Mon Jan 07 12:57:49 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBwEP-0002qF-76 for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 12:57:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBwEM-0004Fx-UD for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 12:57:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07HdPme083283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 10:39:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07HdPRF083282; Mon, 7 Jan 2008 10:39:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07HdOvu083276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jan 2008 10:39:24 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 66C2123E4B3 for ; Mon, 7 Jan 2008 12:39:23 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <003601c850b6$0c3b6c30$24b24490$@net> <000001c850fe$b763deb0$0701a8c0@T60> <4781DB44.7040101@gmail.com> Subject: RE: Markup in atom:name (was RE: Proposal: Atomext WG) Date: Mon, 7 Jan 2008 11:43:17 -0800 Message-ID: <000201c85165$8e127460$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4781DB44.7040101@gmail.com> Thread-Index: AchRA2mwOYW6A0NYQDqvHzhvDs+rZQAYKMiw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07HdPvt083277 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f James M Snell wrote: > With this, I think it is important to look at both the > original intent of the spec and what clients are most likely > to support. While the schema is non-normative, the fact that > atom:name is clearly and specifically marked as "text" in the > schema makes the intent clear. You > *might* be able to stretch really far and claim that escaped > HTML is permitted, but if that was the intent, the spec would > more than likely say so. I think "Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden" is explicit. I just tested Google Reader, IE7, RssBandit, FeedDeamon, and SharpReader. Of those, only SharpReader failed to strip out XHTML markup in an atom:name construct. I think changing atom:name to a text construct is something that could reasonably happen in a minor revision of RFC 4287, but I agree that currently it is not something that everybody should expect to work in every tool. > If you want the Person construct to contain ruby text, the > best approach would be to define an extension element > designed for the purpose of providing a "display" version of > the name, e.g. > > > name > > > name(ruby) > > > ... > > > This would allow existing clients to continue to operate as > they always have. That seems reasonable. It also solves the problem of BIDI text in atom:name, and allows for using Microformats to distinguish between family names and given names. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 13:58:59 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxBb-0004GS-6b for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 13:58:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBxBY-0006UX-Ef for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 13:58:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07IYV8t086986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 11:34:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07IYV0j086985; Mon, 7 Jan 2008 11:34:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07IYT1O086979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jan 2008 11:34:30 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F341323E4A9 for ; Mon, 7 Jan 2008 13:34:28 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Mon, 7 Jan 2008 12:38:24 -0800 Message-ID: <000401c8516d$40529c20$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4782627F.8060001@gmail.com> Thread-Index: AchRU8dsLry4aFOXRrOLvRCz6f/z5AAGXPLg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07IYV1N086980 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 James M Snell wrote: > Brian Smith wrote: > > I agree. If there are going to be formatting codes in the document > > anyway, then why do we need a mechanism that duplicates their > > functionality? > > Because their use in markup is problematic and is actively discouraged > for a number of very good reasons. Even the latest W3C guidelines are now encouraging the use of some formatting characters (LRM and RLM) in addition to markup, where the previous guidelines recommended markup only: http://www.w3.org/TR/i18n-html-tech-bidi/#ri20030218.135304584 So, Atom implementations have to be prepared to accept at least LRM and RLM in documents, anyway. > > My hypothesis is that an implementation ignorant of BIDI issues is > > more likely to preserve the formatting characters than > Atom/XHTML/HTML > > BIDI markup, especially when the effects of those formatting > > characters never span multiple nodes in the document. > > Have you tested this hypothesis using real editors? Example, in our > internal blogging environment, tags are entered in a single text box, > each tag separated by a comma. The system splits the tags into an > array and saves each tag separately. > Each tag becomes a separate atom:category element. Is the user > responsible for adding the appropriate formatting codes around each > individual tag? When the user wishes to edit the entry later, perhaps > to add a new entry, are they supposed to just know that there are > non-visual bidi formatting codes interspersed into the comma separated > list of tags? When software breaks apart BIDI text and recombines it, it has to preserve the BIDI formatting. In this case, the system that splits apart the tags into an array and/or the system that recombines the tags into a comma-seperated list should transparently handle the formatting codes. > You're assuming that all users have the same requirements. > In our environment, a single feed may include entries from many > different users. We have group blogs where users from many different > locales have edit rights on any entry in the blog. Further, our users > use many different editors to write and manage their blog entries. > Asking those users to be mindful of how they're using bidi formatting > characters is a lot more difficult than what we currently do, which is > provide a simple check box to indicate whether or not the entry is > "right-to-left", which in turn, is translated into the appropriate > dir="rtl" in the markup. > > Clients that do not understand the dir attribute simply ignore it, and > since our software is written so that only explicit changes in value > are recognized (e.g. a missing dir attribute does not mean the dir > attribute value has changed) we're able to work seamlessly with > editors that do not support the attribute. In my suggested mechanism, this concern is only relevent for language-sensitive attributes, and atom:name, since that is the only place where XHTML's BIDI markup cannot be used. Even then, it only applies to the few cases where there is a user that is editing part of an entry written in a RTL language, where the Unicode BIDI algorithm fails to work for that part of the entry, they are using software that doesn't support BIDI text entry (meaning they probably can't read or write any RTL languages), and their change somehow still requires the preservation of the RTL base directionality but doesn't require any other formatting codes. I agree that "extremely unlikely" isn't the same as "impossible," but in this case it seems pretty close. > > Markup is just as non-visual as formatting codes, except for people > > using "view source" and the like. > > Yes, but with the marup we don't have to rely on users getting it > right when they type in the values. I agree that we can't rely on users to manually enter formatting codes. But, the software can handle the formatting codes as transparently as it handles the "dir" attribute. > > RFC 4287 and RFC 5023 [are] pretty unclear about what is required to > > be preserved. > > RFC 5023, Section 9.3: To avoid unintentional loss of data when > editing Member Entries or Media Link Entries, an Atom Protocol client > SHOULD preserve all metadata that has not been intentionally modified, > including unknown foreign markup as defined in Section 6 of [RFC4287]. > > Seems pretty darn clear to me. I will illustrate what I am saying with an example. An atom:link element is not unknown foreign markup. So, I can remove atom:link elements whenever I want. In particular, I can remove an atom:link element and then replace it with an another atom:link element that links to the same destination. That doesn't violate the specification but the old element might have a "dir" attribute and the new one might not. > 9.3 uses the term "unknown foreign markup", which, if RFC > 4287 defines as unknown elements AND attributes. I don't see that anywhere in RFC 4287. Even if it was there, it would be very problematic to support that in all situations, and I would recommend against anybody depending on implementations to preserve unknown attributes on known elements, especially when the content of those known elements is being modified. > > The category labels are almost always going to be composed of strong > > RTL and strong LTR characters (only), so the BIDI algorithm will > > work correctly. And, when it doesn't work, it is unlikely that it > > will be due to the wrong base directionality--in these cases, > > formatting characters are going to be needed no matter what. Right? > > "almost always" is not "always". The Atom bidi draft covers the cases > where "always" is more desirable than "almost always". Please give an example of a category label that requires RTL base directionality, fails to be rendered correctly using the Unicode BIDI algorithm, doesn't require any directionality modifiers other than the base directionality, which your software supports, and which you expect every Atom implementation to support. AFIACT, this would be a label that starts or ends with punctuation, or is a mixture of LTR and RTL text, with punctuation at the point where the directionality changes. > And no, the formatting characters are not always going to be needed. > If I am rendering the text in (x)html, I don't want the formatting > characters in there at all; rather, I want to follow best practices > and use the (x)html provided bidi markup mechanisms. I agree 100%. A BIDI-enabled Atom-to-HTML converter should always convert Unicode formatting characters to markup, whenever possible. > Failing to implement the atom bidi spec has significantly fewer > consequences than improperly implementing the unicode formatting > characters. That is, existing applications will be no worse off than > they currently are if the dir attribute is ignored or dropped; > however, existing applications can be severely impacted by the > improper use of the unicode bidi characters. Again, there are very > good reasons behind the recommendation against using the formatting > codes in markup. Right, that is why my suggestion uses XHTML markup whenever possible, and fall back to formatting codes only as a last resort. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 14:20:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxWe-0007PN-6i for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 14:20:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBxWd-0006yt-NM for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 14:20:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07IoUpV088542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 11:50:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07IoUEE088541; Mon, 7 Jan 2008 11:50:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07IoSNg088530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jan 2008 11:50:30 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4AF0A23E4BA for ; Mon, 7 Jan 2008 13:50:28 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Mon, 7 Jan 2008 12:54:23 -0800 Message-ID: <000501c8516f$7c194630$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4782627F.8060001@gmail.com> Thread-Index: AchRU8dsLry4aFOXRrOLvRCz6f/z5AAGskzQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07IoUNf088536 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 James M Snell wrote: > I wrote: > > My hypothesis is that an implementation ignorant of BIDI issues is > > more likely to preserve the formatting characters than > > Atom/XHTML/HTML BIDI markup, especially when the effects of > > those formatting characters never span multiple nodes in the > > document. > > Have you tested this hypothesis using real editors? To clarify, I was thinking more of how aggregators and other non-interactive processors will treat markup vs. formatting codes. In my limited testing, I was able to get formatting codes to be preserved by AtomPub servers but I not always able to get the "dir" attribute preserved. > >> Also, imagine a case where we have a feed with 100 > >> entries, each with about 5 atom:category elements. > >> Let's stay that the feed is generally all RTL. Using > >> your approach, that's at least 1000 extra > >> characters in the feed, and 500 opportunities for the > >> embedding to be screwed up. > > > > The category labels are almost always going to be composed > > of strong RTL and strong LTR characters (only), so the > > BIDI algorithm will work correctly. And, when it doesn't > > work, it is unlikely that it will be > > due to the wrong base directionality--in these cases, formatting > > characters are going to be needed no matter what. Right? > > "almost always" is not "always". The Atom bidi draft covers > the cases where "always" is more desirable than "almost always". Here, I meant that using formatting codes would not result in 1000 extra characters, but almost no extra characters. Also, it is unlikely that errnoeously placed embedding characters will cause major problems since they are all localized to attribute values and atom:name in my suggested mechanism, and there is no cascading/inheritance of directionality that mechanism. In other words, any improper embedding will be limited and very localized. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 14:45:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBxuJ-0006Nq-4j for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 14:45:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBxuH-0007Qo-Vf for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 14:45:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07JSK3H091964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 12:28:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07JSKsb091963; Mon, 7 Jan 2008 12:28:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07JSJ84091956 for ; Mon, 7 Jan 2008 12:28:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so1432335anc.44 for ; Mon, 07 Jan 2008 11:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=MVRXFkk4tI9vUS3jhVtDUBSpZpca0kLwetBaFjS9tRw=; b=sHO3FNoMojKNWK5NJjkNON1FcVgZ4Yhu06j6OUaV6cjgkvqqVjCGosWfANu7DzIvs7FgiyFpOAPupS2IpcZdPCI84Usvn9Y64E2FzmhJvUxSTWaJO4yO1BbsY2nMZF6+83v8VCAiRniosXGx9L+JfAwwCpAp4RClYFS6i1vY5CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=whZPcn9G4gTAMbZtI706L09PQtAzClLpc9wyloZ0mkBcrZgJf9HQtRoNjTOosdvypB0S2GxBghwLr4vob3HH4WKcCX3T2oiuM5LvZfcjEORG0XJL67bc7MVS0A55HUVESyd7mN/x6nUeBnbcJzl/prdWhR+rG6VIgIYtw1o5deE= Received: by 10.100.202.9 with SMTP id z9mr1141875anf.80.1199734099260; Mon, 07 Jan 2008 11:28:19 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 7sm6508029hsx.4.2008.01.07.11.28.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jan 2008 11:28:18 -0800 (PST) Message-ID: <47827D4F.3040300@gmail.com> Date: Mon, 07 Jan 2008 11:28:15 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: BIDI (was Proposal: Atomext WG) References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> <000401c8516d$40529c20$2401a8c0@T60> In-Reply-To: <000401c8516d$40529c20$2401a8c0@T60> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Brian Smith wrote: > James M Snell wrote: >> Brian Smith wrote: >>> I agree. If there are going to be formatting codes in the document >>> anyway, then why do we need a mechanism that duplicates their >>> functionality? >> Because their use in markup is problematic and is actively discouraged >> for a number of very good reasons. > > Even the latest W3C guidelines are now encouraging the use of some formatting characters (LRM and RLM) in addition to markup, where the previous guidelines recommended markup only: > > http://www.w3.org/TR/i18n-html-tech-bidi/#ri20030218.135304584 > The guidelines state, very clearly, that the formatting characters should not be used when markup can be used instead. The LRM and RLM characters do not have markup alternatives and do not carry the same risks as the other formatting characters. This recommendation is very consistent, and is upheld by the Atom bidi draft, which provides a markup alternative to using the formatting characters. Furthermore, the guidelines also state a best practice to "[u]se bidi markup only when necessary.", and gives the specific recommendation that "[o]nce you have established the appropriate directionality for the html element you will only need to apply bidi markup to a block element if you want that element's directionality to be different." By moving the dir as far up in the document tree as possible "simplif[ies] the document and reduce[s] bandwidth requirements." > So, Atom implementations have to be prepared to accept at least LRM and RLM in documents, anyway. > Never said they didn't. All the atom bidi draft does is provide a markup alternative in order to make life easier... which, reminds me, you still haven't explained why you think the dir attribute is more complicated to implement than the bidi characters. >>> My hypothesis is that an implementation ignorant of BIDI issues is >>> more likely to preserve the formatting characters than >> Atom/XHTML/HTML >>> BIDI markup, especially when the effects of those formatting >>> characters never span multiple nodes in the document. >> Have you tested this hypothesis using real editors? Example, in our >> internal blogging environment, tags are entered in a single text box, >> each tag separated by a comma. The system splits the tags into an >> array and saves each tag separately. >> Each tag becomes a separate atom:category element. Is the user >> responsible for adding the appropriate formatting codes around each >> individual tag? When the user wishes to edit the entry later, perhaps >> to add a new entry, are they supposed to just know that there are >> non-visual bidi formatting codes interspersed into the comma separated >> list of tags? > > When software breaks apart BIDI text and recombines it, it has to preserve > the BIDI formatting. In this case, the system that splits apart the tags > into an array and/or the system that recombines the tags into a comma-seperated > list should transparently handle the formatting codes. > Let me ask again: is the user responsible for adding the appropriate formatting codes around each individual tag in the list? When the user wishes to edit the entry later, are they supposed to just know that there are non-visual bidi formatting codes interspersed into the comma separated list of tags? >> You're assuming that all users have the same requirements. >> In our environment, a single feed may include entries from many >> different users. We have group blogs where users from many different >> locales have edit rights on any entry in the blog. Further, our users >> use many different editors to write and manage their blog entries. >> Asking those users to be mindful of how they're using bidi formatting >> characters is a lot more difficult than what we currently do, which is >> provide a simple check box to indicate whether or not the entry is >> "right-to-left", which in turn, is translated into the appropriate >> dir="rtl" in the markup. >> >> Clients that do not understand the dir attribute simply ignore it, and >> since our software is written so that only explicit changes in value >> are recognized (e.g. a missing dir attribute does not mean the dir >> attribute value has changed) we're able to work seamlessly with >> editors that do not support the attribute. > > In my suggested mechanism, this concern is only relevent for language-sensitive > attributes, and atom:name, since that is the only place where XHTML's BIDI > markup cannot be used. Even then, it only applies to the few cases where there > is a user that is editing part of an entry written in a RTL language, where > the Unicode BIDI algorithm fails to work for that part of the entry, they are > using software that doesn't support BIDI text entry (meaning they probably can't > read or write any RTL languages), and their change somehow still requires the > preservation of the RTL base directionality but doesn't require any other formatting > codes. I agree that "extremely unlikely" isn't the same as "impossible," but in > this case it seems pretty close. > Your solution is based on a lot of assumptions and possibilities. It *may* work in *many* cases. It *likely* won't be a problem. It's *possible* that clients will get it right. It also goes against documented best practices and recommendations, defended only by an untested hypothesis that it's "simple" and "easy". That's not acceptable when we can do better. The Atom bidi attribute is not the whole solution; it's just one part of the larger picture, intended to fill in the gaps and make certain things simpler. Further, it is consistent with the approach taken by XHTML and the recommendations of both the W3C and the Unicode organization. > [snip] >>> RFC 4287 and RFC 5023 [are] pretty unclear about what is required to >>> be preserved. >> RFC 5023, Section 9.3: To avoid unintentional loss of data when >> editing Member Entries or Media Link Entries, an Atom Protocol client >> SHOULD preserve all metadata that has not been intentionally modified, >> including unknown foreign markup as defined in Section 6 of [RFC4287]. >> >> Seems pretty darn clear to me. > > I will illustrate what I am saying with an example. An atom:link element > is not unknown foreign markup. So, I can remove atom:link elements whenever > I want. In particular, I can remove an atom:link element and then replace > it with an another atom:link element that links to the same destination. > That doesn't violate the specification but the old element might have a > "dir" attribute and the new one might not. Ok... and? The meaning of the text in the spec is clear: clients should only change things they intentionally want changed. If the atom:link element is replaced without the dir attribute, then obviously the only reasonable interpretation the server can make is that the client wanted that dir attribute to be changed. > [snip] - James From owner-atom-syntax@mail.imc.org Mon Jan 07 15:46:10 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JByrK-0002bi-CN for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 15:46:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JByrJ-00009x-Cf for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 15:46:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07KYKT9096657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 13:34:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07KYK7i096656; Mon, 7 Jan 2008 13:34:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07KYJOn096648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jan 2008 13:34:20 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4E75423E4A9 for ; Mon, 7 Jan 2008 15:34:18 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> <000401c8516d$40529c20$2401a8c0@T60> <47827D4F.3040300@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Mon, 7 Jan 2008 14:38:13 -0800 Message-ID: <000701c8517d$fd70a940$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47827D4F.3040300@gmail.com> Thread-Index: AchRY/98EGBBq1vjQi6+MOUZiGS9CQAEf7VQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07KYKOm096651 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 James M Snell wrote: > > So, Atom implementations have to be prepared to accept at > least LRM and RLM in documents, anyway. > > > > Never said they didn't. All the atom bidi draft does is > provide a markup alternative in order to make life easier... > which, reminds me, you still haven't explained why you think > the dir attribute is more complicated to implement than the > bidi characters. * A processor still has to handle the formatting characters regardless of whether the document uses the Atom BIDI markup. * The inheritance of directionality makes it more difficult to compose, decompose, and remix atom documents than if the directionality markup was localized near the text that needs it. * In my testing, current Atom(Pub) implementations were more likely to strip the "dir" attribute than they were to strip Unicode formatting characters. * My code already preserves BIDI directionality information encoded using the mechanism I suggested this thread, with no extra work on my part. Since the preservation of the formatting characters and (X)HTML BIDI markup required literally ZERO lines of code on my part, and support for the Atom BIDI draft requires more than zero lines of code, I find the Atom BIDI draft to be more difficult to implement. * The suggested mechanism doesn't all > > When software breaks apart BIDI text and recombines it, it has to > > preserve the BIDI formatting. In this case, the system that splits > > apart the tags into an array and/or the system that recombines the > > tags into a comma-seperated list should transparently > > handle the formatting codes. > > > > Let me ask again: is the user responsible for adding the appropriate > formatting codes around each individual tag in the list? Not if you don't already need to using your current implementation. Let's say the uesr has a list "abc, FED, ghi" with no control characters and checks the RTL checkbox. You break it into the three parts and store it in an array or database or wherever, along with the checkbox value. When you want to regenerate the list, you take all the entries and join then with ", ", you set the text box's directionality using the checkbox value, and then you put the regenerated list back in the text box--again, no formatting codes. When you generate your atom document, you don't need a "dir" attribute or unicode control characters for the @label value, because the BIDI algorithm will handle everything correctly. That is assuming that the BIDI algorithm can already handle the list of labels without hints. If you send me some examples of labels that are not BIDI-algorithm-friendly (preferably ones that that your implementation supports), I will explain when the control characters are necessary. > When the user wishes to edit the entry later, are they supposed > to just know that there are non-visual bidi formatting codes > interspersed into the comma separated list of tags? No, I am not recommending that. The only case where that would be necessary is when you need to have nested embedding levels in your list of tags. That seems to be something that your implementation doesn't support anyway, based on your description. > Your solution is based on a lot of assumptions and possibilities. It > *may* work in *many* cases. It *likely* won't be a problem. It's > *possible* that clients will get it right. It also goes against > documented best practices and recommendations, defended only by an > untested hypothesis that it's "simple" and "easy". That's not > acceptable when we can do better. My main assumption is that very few implementations will implement the Atom BIDI mechanism properly or consistently. Consequently, I want to focus on a solution that can be "accidently" implemented correctly, as much as possible. I guess I am just playing the "worse is better" card. I've asked you multiple times to supply some concrete examples where my idea breaks down (for BIDI IRI templates and for BIDI in Atom). Those requests were not rhetorical--having those examples really makes everything easier to understand for people like me, who aren't experts in BIDI text handling. Do you have links to real feeds that makes good use of the Atom BIDI draft features, or some other real-world examples, so we can study them? > The Atom bidi attribute is not the whole solution; it's just > one part of the larger picture, intended to fill in the gaps > and make certain things simpler. Further, it is consistent > with the approach taken by XHTML and the recommendations of > both the W3C and the Unicode organization. I never doubted that. The only thing I doubt is that it is better or simpler to have a seperate mechanism for BIDI than the mechanism for Ruby text or other i18n problems with RFC 4287. I really liked your idea of a element to solve the problem with Ruby text in . That same solution also be applied to atom:link/@title and atom:category/@label to allow all language-sensitive constructs in RFC 4287 to be compliant with the "Unicode in XML" guidelines. And, coincidently, it would also work for BIDI text and probably even Gaiji (which I didn't even know about until Murata-san mentioned it). I really think that the "use XHTML text constructs for i18n" idea is easy to understand and relatively simple to implement, particularly since the cascading/inheriting of directionality overrides becomes very localized. > Ok... and? The meaning of the text in the spec is clear: > clients should only change things they intentionally want > changed. If the atom:link element is replaced without the > dir attribute, then obviously the only reasonable > interpretation the server can make is that the client > wanted that dir attribute to be changed. I am not talking about clients stripping the directionality information as much as servers stripping it. For example, in my AtomPub implementation, the server ignores any changes to "edit" and "edit-media" links, and any changes to atom:content for media link entries, including all attributes. I had difficulty with getting other AtomPub servers to preserve the "dir" attribute except on XHTML elements. It is my understanding that every server can strip off the "dir" attribute if it wants to. Do you know of any servers that preserve it? Regards, Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 16:31:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBzZJ-0005mp-NO for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 16:31:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBzZJ-00011Y-6F for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 16:31:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07LISOb099743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 14:18:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07LISwu099742; Mon, 7 Jan 2008 14:18:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07LIRYR099736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Jan 2008 14:18:28 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id ED86023E3AB for ; Mon, 7 Jan 2008 16:18:26 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> <000401c8516d$40529c20$2401a8c0@T60> <47827D4F.3040300@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Mon, 7 Jan 2008 15:22:21 -0800 Message-ID: <000801c85184$28273450$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47827D4F.3040300@gmail.com> Thread-Index: AchRY/98EGBBq1vjQi6+MOUZiGS9CQAHVR6Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07LISYQ099737 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d James M Snell wrote: > The guidelines state, very clearly, that the formatting > characters should not be used when markup can be used > instead. The LRM and RLM characters do not have markup > alternatives and do not carry the same risks as the other > formatting characters. This recommendation is very > consistent, and is upheld by the Atom bidi draft, which > provides a markup alternative to using the formatting characters. > > Furthermore, the guidelines also state a best practice to > "[u]se bidi markup only when necessary.", and gives the How about a compromise? You don't like formatting codes, but they can't completely go away. I don't like the inheritance/cascading of directionality between atom elements because I think it is easy to get wrong. How about this: * Don't allow @dir on atom:feed. This makes it easier to copy entries to/from a feed without requiring rewriting. It also makes digital signatures on entries easier to deal with. * Don't allow @dir on atom:entry. Again, this reduces the likelihood that a processor will screw up the inheritance of directionality overrides. It also means that different users can more easily edit different pieces of metadata without clobbering each other's directionality overrides. * Don't allow @dir on atom:content or text constructs. XHTML should be used instead, and the @dir should appear on the xhtml:div element of the text construct. This eliminates the other major case where a process will screw of the inheritance of directionality overrides, and increases the likelihood that processors will preserve the directionality information since it will be in the XHTML and not in the Atom markup. * When any Unicode formatting characters are encountered, they must override the directionality in @dir. However, using formatting characters is "NOT RECOMMENDED." * Future language-sensitive extensions to Atom are strongly "RECOMMENDED" to use text constructs for all language-sensitive text. * Punt on Ruby text for now. > "[o]nce you have established the appropriate directionality > for the html element you will only need to apply bidi markup > to a block element if you want that element's directionality > to be different." By moving the dir as far up in the > document tree as possible "simplif[ies] the document and > reduce[s] bandwidth requirements." This recommendation is good for HTML because a HMTL document is usually not processed as a collection of individual parts, but instead as an indivisible document. However, it is counter-productive for Atom because Atom feeds ARE collections of individual documents. - Brian From owner-atom-syntax@mail.imc.org Mon Jan 07 17:48:12 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0lQ-0002ay-M9 for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 17:48:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0lQ-0002O8-78 for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 17:48:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07MWlBU004473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 15:32:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07MWlgM004472; Mon, 7 Jan 2008 15:32:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07MWgVn004463 for ; Mon, 7 Jan 2008 15:32:42 -0700 (MST) (envelope-from dave@djpowell.net) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20080107223402.XRVQ20647.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Mon, 7 Jan 2008 22:34:02 +0000 Received: from DavePC ([86.4.233.237]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20080107223457.RPNM26699.aamtaout03-winn.ispmail.ntl.com@DavePC>; Mon, 7 Jan 2008 22:34:57 +0000 From: "David Powell" To: "'James M Snell'" , "'Brian Smith'" Cc: "'atom-syntax'" References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> <000401c8516d$40529c20$2401a8c0@T60> <47827D4F.3040300@gmail.com> In-Reply-To: <47827D4F.3040300@gmail.com> Subject: RE: BIDI (was Proposal: Atomext WG) Date: Mon, 7 Jan 2008 22:32:37 -0000 Message-ID: <014001c8517d$36a08330$a3e18990$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchRZMHLQwGGDnDWRm+ltgY1LzXwXwAFKx8A Content-Language: en-gb Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m07MWlVn004467 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > The guidelines state, very clearly, that the formatting characters > should not be used when markup can be used instead. But markup cannot be used inside XML attributes. Read "Best Practice 11". It describes our situation exactly: [...] On the other hand, attribute text and element text that allows no internal markup, ie. the title, textarea and option elements, cannot support use of dir on a span or other element to label part of its content. In these cases you can use Unicode characters to do the same job. The following table shows correspondences between markup and Unicode control codes: [...] RLE LRE RLO LRO PDF [...] The joint Unicode Technical Report #20 and W3C Note, Unicode in XML and other Markup Languages goes further. It explicitly recommends that only the markup be used [...] Of course, in attribute values or for the three elements listed above markup cannot be used, so the Unicode control characters are the only option available. Do you disagree with these findings? Do you have a better way to implement bidi embedding in attribute values or PCDATA elements? The atom-bidi draft does not support bidi embedding. If you are representing bidi text in a scope that supports internal markup you can either use Unicode or mixed content markup; and mixed content markup is the prefered choice. If you are representing bidi text in a scope that does not support internal markup - which is what we are discussing here - then Unicode is the only choice. -- Dave From owner-atom-syntax@mail.imc.org Mon Jan 07 18:00:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0x8-0006zG-CK for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 18:00:18 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC0x7-0002XR-U7 for atompub-archive@lists.ietf.org; Mon, 07 Jan 2008 18:00:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07MlJQT005076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2008 15:47:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m07MlJoj005075; Mon, 7 Jan 2008 15:47:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m07MlIkc005067 for ; Mon, 7 Jan 2008 15:47:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by hs-out-2122.google.com with SMTP id 55so5899413hsc.10 for ; Mon, 07 Jan 2008 14:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=7y/sqdUKQD8de1V0eQknXFbkSxUAQbr5MrvxIfUBEQ4=; b=Suj4cBrZR980IqFOgz430dXAL/rps1Rh/3KKJf9AjCRFe1QyOK8bHjz4YXGtD1hxgKayxbupI9du5QXJtY/cKvMimBrVImz9vpp4qP21GY6WzeBxTtXDFtfq4F2zCY4ZhGqv2qxOz5ZpHr+EQ4TkOqYmuzGHMsV8YGWLY2pg8+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=vqHkVzsspRrxTGSodkR9TkLPjqmI3laZbgKil3CxtGvk4dRgmf+aqfshlJlr8+Slejz154F/BHui5Cychix/rlnZp65nP5CXzc5XGesI2eXxq6WSv6oiSTeVGFljRIfQDg+cjJSk6MRwG/DIE/VqJ/3H/ZNY2Q4RTUguq/DZUx4= Received: by 10.142.127.10 with SMTP id z10mr4980263wfc.216.1199746036561; Mon, 07 Jan 2008 14:47:16 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id s38sm942430rnb.13.2008.01.07.14.47.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jan 2008 14:47:15 -0800 (PST) Message-ID: <4782ABE8.3040905@gmail.com> Date: Mon, 07 Jan 2008 14:47:04 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: David Powell CC: "'Brian Smith'" , "'atom-syntax'" Subject: Re: BIDI (was Proposal: Atomext WG) References: <477D6F63.7090503@gmail.com> <000101c850ab$31d0db20$0301a8c0@T60> <47817F50.2070409@gmail.com> <000101c850fe$b7d16d90$0701a8c0@T60> <4781D89B.3080301@gmail.com> <000101c8515a$fec4dc80$2401a8c0@T60> <4782627F.8060001@gmail.com> <000401c8516d$40529c20$2401a8c0@T60> <47827D4F.3040300@gmail.com> <014001c8517d$36a08330$a3e18990$@net> In-Reply-To: <014001c8517d$36a08330$a3e18990$@net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Let me say it again: the atom-bidi draft does not replace the use of the formatting characters. There are cases where the formatting characters will still be needed. I never said using the unicode characters was not an option; just that they weren't recommended. The *only* thing the atom-bidi draft does is provide a way of specifying the default direction of directionally neutral text. It does not attempt to replace the functionality of the bidi formatting characters. The bidi draft does provide a markup alternative to using the bidi formatting codes when all that is needed is the ability to specify a default direction for all the text in the feed, entry, etc. If you need anything more complicated than that, then you fall back to the unicode characters, which is not recommended but is still an option. - James David Powell wrote: > [snip] > > Do you have a better way to implement bidi embedding in attribute values or PCDATA elements? The atom-bidi draft does not support bidi embedding. > > If you are representing bidi text in a scope that supports internal markup you can either use Unicode or mixed content markup; and mixed content markup is the prefered choice. > > If you are representing bidi text in a scope that does not support internal markup - which is what we are discussing here - then Unicode is the only choice. > From owner-atom-syntax@mail.imc.org Tue Jan 08 10:19:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGF4-00044d-Uk for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 10:19:50 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCGF3-00026D-6Y for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 10:19:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08EsKAA060992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 07:54:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m08EsKSP060991; Tue, 8 Jan 2008 07:54:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08EsIV1060985 for ; Tue, 8 Jan 2008 07:54:19 -0700 (MST) (envelope-from nojorin@gmail.com) Received: by hs-out-2122.google.com with SMTP id 55so6180871hsc.10 for ; Tue, 08 Jan 2008 06:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UsD66hXBFi1Jzl2TCgYs4wh8fP9IU1TyOlgnzo8rBQM=; b=G44S5Ljgl5pPoFsAEeXNER6y6QlmHv5brztWsYsteiElQFsG9dNa29JsNmlnCWh11m3hXZkCHZ4aaoFULIHU5456RNFMTF5RnaQgHAw9bHPazjjzRqgDHT5r8RuzEHK05t1wERBA6YpWNYiroQ/0+P3a/ZHJFSFUpLfnGV73Pvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oL5A3ppn4DwKEyqtNiE0N/dJx6AD5Ct31N1f0YCZ9Gh6v35hwibJLHVFMls+cDaIHO5Cb4gQdQbvC7LhUE7LlvJLPH5WfIdZ92XMSRS+GOUFIqEZbFTXjOuHt+Y3MVG+G9pdIISXLJeF1+JBphyIBDFk9cIFtw8uJeG839MZLmA= Received: by 10.143.121.5 with SMTP id y5mr244208wfm.223.1199804057453; Tue, 08 Jan 2008 06:54:17 -0800 (PST) Received: by 10.142.216.3 with HTTP; Tue, 8 Jan 2008 06:54:17 -0800 (PST) Message-ID: Date: Tue, 8 Jan 2008 23:54:17 +0900 From: "Tatsuya Noyori" To: atom-syntax@imc.org Subject: Re: Updated Tombstones Draft, Take 2 In-Reply-To: <000d01c850a2$44b202e0$0301a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hello, I have two requests to the tombstones. Request No. 1. analogy syntax: I like Atom syntax. And I think analogy is important. So I hope that the tombstones is similar in syntax to Atom syndication format. The syntax is as follows: ... tag:example.org,2005:/entries/2 2005-11-29T12:11:12Z ... tag:example.org,2005:/entries/2 2005-11-29T12:11:12Z John Doe jdoe@example.org Request No. 2. sync to Media Entry: I hope Sync covers Media Entry, such as image files or pdf files. And I think Media Entry needs Atom Feed like the following. Test.gif http://localhost:8080/roller/roller-services/app/Tokyo/resource/images/Test.gif 2007-11-02T05:20:58Z 2007-11-02T05:20:58Z And I think Atom Feed of Media Entry needs the following tombstones. ... http://localhost:8080/roller/roller-services/app/Tokyo/resource/images/Test.gif 2005-11-29T12:11:12Z ... http://localhost:8080/roller/roller-services/app/Tokyo/resource/images/Test.gif 2005-11-29T12:11:12Z John Doe jdoe@example.org -- Tatsuya Noyori (^o^)/ From owner-atom-syntax@mail.imc.org Tue Jan 08 11:31:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCHM5-00061Q-IU for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 11:31:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCHM3-0003Zv-88 for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 11:31:09 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08GFkQJ066731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 09:15:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m08GFkT1066730; Tue, 8 Jan 2008 09:15:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08GFjd2066720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jan 2008 09:15:46 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [209.169.80.164]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9EB26D05A1 for ; Tue, 8 Jan 2008 11:15:44 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> Subject: RE: Updated Tombstones Draft, Take 2 Date: Tue, 8 Jan 2008 10:19:32 -0800 Message-ID: <000301c85223$08d5c720$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchSCDYLioV+0I3yQkaiuMxnWsXTwwAGGlsg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Tatsuya Noyori wrote: > I like Atom syntax. And I think analogy is important. So I > hope that the tombstones is similar in syntax to Atom > syndication format. I agree. > I hope Sync covers Media Entry, such as image files or pdf > files. And I think Media Entry needs Atom Feed like the following. > > > Test.gif > href="http://localhost:8080/roller/Tokyo/resource/images/Test.gif"/> > > http://localhost:8080/roller/roller-services/app/Tokyo/res > ource/images/Test.gif > 2007-11-02T05:20:58Z > 2007-11-02T05:20:58Z > > > > As a RFC 5023 media link entry, it would look like this: Test.gif http://localhost:8080/roller/roller-services/app/Tokyo/resource/imag es/Test.gif 2007-11-02T05:20:58Z 2007-11-02T05:20:58Z > > > href="http://localhost:8080/roller/Tokyo/resource/images/Test.gif"/> > > http://localhost:8080/roller/roller-services/app/Tokyo/ > resource/images/Test.gif > 2005-11-29T12:11:12Z > > John Doe > jdoe@example.org > > > An AtomPub client that depends on anything more than that element being present in a tombstone is going to be non-portable. For that reason, I recommend against putting additional information in the tombstone. Anyway, it is better to specify the trash/soft delete/undelete mechanism seperately from the tombstone mechanism. - Brian From owner-atom-syntax@mail.imc.org Tue Jan 08 12:57:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCIhA-0004kf-9P for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 12:57:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCIh9-0004sL-Te for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 12:57:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08HW9TH071963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 10:32:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m08HW9GF071962; Tue, 8 Jan 2008 10:32:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc2-s30.bay0.hotmail.com (bay0-omc2-s30.bay0.hotmail.com [65.54.246.166]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08HW62X071953 for ; Tue, 8 Jan 2008 10:32:08 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.16]) by bay0-omc2-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jan 2008 09:32:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Jan 2008 09:32:05 -0800 Message-ID: Received: from 85.211.254.81 by BAY141-DAV6.phx.gbl with DAV; Tue, 08 Jan 2008 17:32:04 +0000 X-Originating-IP: [85.211.254.81] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "'atom-syntax'" References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> <000301c85223$08d5c720$2401a8c0@T60> Subject: Re: Updated Tombstones Draft, Take 2 Date: Tue, 8 Jan 2008 17:32:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 08 Jan 2008 17:32:05.0832 (UTC) FILETIME=[63488C80:01C8521C] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Brian Smith wrote: > Tatsuya Noyori wrote: >> I like Atom syntax. And I think analogy is important. So I >> hope that the tombstones is similar in syntax to Atom >> syndication format. > > I agree. Do either of you have a technical reason for your preference? Efficiency, interoperability, ease of implementation - anything like that? Or is this just an aesthetic issue for you? Regards James From owner-atom-syntax@mail.imc.org Tue Jan 08 13:55:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJbX-0008Pz-1B for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 13:55:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCJbV-0005mt-6J for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 13:55:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08IUpCs075721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 11:30:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m08IUpgQ075720; Tue, 8 Jan 2008 11:30:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08IUoic075713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jan 2008 11:30:51 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [209.169.80.164]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 85FAED05AF for ; Tue, 8 Jan 2008 13:30:48 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> <000301c85223$08d5c720$2401a8c0@T60> Subject: RE: Updated Tombstones Draft, Take 2 Date: Tue, 8 Jan 2008 12:34:36 -0800 Message-ID: <000701c85235$e78cae40$2401a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchSHiOcIm9+JT8rR0OqsudbRamInQAEsXwg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 James Holderness wrote: > Brian Smith wrote: > > Tatsuya Noyori wrote: > >> I like Atom syntax. And I think analogy is important. So I > hope that > >> the tombstones is similar in syntax to Atom syndication format. > > > > I agree. > > Do either of you have a technical reason for your preference? > Efficiency, interoperability, ease of implementation - > anything like that? Or is this just an aesthetic issue for you? The main benefit is that the syntax and semantics can be completely delegated to RFC 4287 with minimal verbage. Even if you haven't read the tombstone spec, when you see an element, its syntax and semantics (especially the comparison rules and lack of a guarentee of dereferencability) are immediately clear. At the very least, I expect that the syntax of the timestamp to be consistent with RFC 4287 and RFC 5023, which means using "date construct" elements. It the timestamp is going to be an element then why not make the ID an element as well? RFC 5023 did a good job of reusing the RFC 4287 syntax whenever possible. I thnk that is a practice that should be followed by other extensions to RFC 4287. At the very least, such a policy will reduce the need to discuss syntax and allow more time to discuss semantics. http://www.informatik.uni-kiel.de/%7emh/curry/listarchive/0017.html - Brian From owner-atom-syntax@mail.imc.org Tue Jan 08 17:07:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCMbL-0005Yi-QE for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 17:07:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCMbK-0001H6-7U for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 17:07:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08LksWR091239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 14:46:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m08Lksho091238; Tue, 8 Jan 2008 14:46:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08LkqsW091230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jan 2008 14:46:53 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.110] (unknown [121.44.238.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 1457023E49C; Tue, 8 Jan 2008 16:46:50 -0500 (EST) Cc: "'atom-syntax'" Message-Id: <00101B2E-1E42-4D3E-9E05-694D70C2058B@mnot.net> From: Mark Nottingham To: Brian Smith In-Reply-To: <000301c85223$08d5c720$2401a8c0@T60> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Updated Tombstones Draft, Take 2 Date: Wed, 9 Jan 2008 08:46:39 +1100 References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> <000301c85223$08d5c720$2401a8c0@T60> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On 09/01/2008, at 5:19 AM, Brian Smith wrote: > > Tatsuya Noyori wrote: >> I like Atom syntax. And I think analogy is important. So I >> hope that the tombstones is similar in syntax to Atom >> syndication format. > > I agree. +1 Having a different syntactic style forces people to re-learn it, acting as a barrier to entry and giving them another chance to mess it up. When someone has gone to the trouble of knowing where to put an ID in an Atom entry, for example, it seems strange to make them re-learn where to put it in a tombstone. I'm not lie-down-in-the-road about it, just seems like the sensible way to do things to me. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Jan 08 18:19:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCNj1-0004Y9-H4 for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 18:19:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCNj1-000327-3X for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 18:19:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08MxLjg096242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 15:59:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m08MxL4H096241; Tue, 8 Jan 2008 15:59:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s9.bay0.hotmail.com (bay0-omc3-s9.bay0.hotmail.com [65.54.246.209]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m08MxKHS096234 for ; Tue, 8 Jan 2008 15:59:21 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.18]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jan 2008 14:59:20 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Jan 2008 14:59:20 -0800 Message-ID: Received: from 85.211.254.81 by BAY141-DAV8.phx.gbl with DAV; Tue, 08 Jan 2008 22:59:16 +0000 X-Originating-IP: [85.211.254.81] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "'atom-syntax'" References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> <000301c85223$08d5c720$2401a8c0@T60> <00101B2E-1E42-4D3E-9E05-694D70C2058B@mnot.net> Subject: Re: Updated Tombstones Draft, Take 2 Date: Tue, 8 Jan 2008 22:59:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 08 Jan 2008 22:59:20.0540 (UTC) FILETIME=[1A7B39C0:01C8524A] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Mark Nottingham wrote: > On 09/01/2008, at 5:19 AM, Brian Smith wrote: >> Tatsuya Noyori wrote: >>> I like Atom syntax. And I think analogy is important. So I >>> hope that the tombstones is similar in syntax to Atom >>> syndication format. >> >> I agree. > > +1 > > Having a different syntactic style forces people to re-learn it, acting > as a barrier to entry and giving them another chance to mess it up. When > someone has gone to the trouble of knowing where to put an ID in an Atom > entry, for example, it seems strange to make them re-learn where to put > it in a tombstone. And yet the syntax that Tatsuya Noyori suggested, Brian agreed with, and you +1ed, didn't actually use an atom:id - the id was in the tombstone namespace. Getting that confused, seems to me a far more likely problem. I'll admit that the issue could be argued either way, but I still think the benefits of using attributes outweigh any advantage that might be gained by having a partially shared syntax with RFC4287. Regards James From owner-atom-syntax@mail.imc.org Tue Jan 08 19:28:36 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCOo8-0000hS-Jb for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 19:28:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCOo8-0003jJ-4V for atompub-archive@lists.ietf.org; Tue, 08 Jan 2008 19:28:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m090EReW000574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 17:14:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m090ERR3000573; Tue, 8 Jan 2008 17:14:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m090EP83000565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jan 2008 17:14:26 -0700 (MST) (envelope-from mnot@mnot.net) Received: from localhost (unknown [216.145.54.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id B4BABD0562; Tue, 8 Jan 2008 19:14:23 -0500 (EST) From: Mark Nottingham To: James Holderness In-Reply-To: Subject: Re: Updated Tombstones Draft, Take 2 X-Priority: 3 References: <477EDC91.6020504@gmail.com> <73ec599d0801050417h7c5cd354h9f5730834c3cf055@mail.gmail.com> <477FFC14.2090604@gmail.com> <000d01c850a2$44b202e0$0301a8c0@T60> <000301c85223$08d5c720$2401a8c0@T60> <00101B2E-1E42-4D3E-9E05-694D70C2058B@mnot.net> Message-Id: <9EA89944-AF8E-460D-A84D-DCB8F8570547@mnot.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 9 Jan 2008 11:14:18 +1100 Cc: "'atom-syntax'" X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 09/01/2008, at 9:59 AM, James Holderness wrote: > And yet the syntax that Tatsuya Noyori suggested, Brian agreed > with, and you +1ed, didn't actually use an atom:id - the id was in > the tombstone namespace. Getting that confused, seems to me a far > more likely problem. Good point. My preference would be to put it all in the Atom namespace, as elements. If that's controversial (either because it's using atom:id et al out of context, or because of the namespace issue), attributes are the path of least resistance. Cheers, -- Mark Nottingham http://www.mnot.net/ From Traci.nusbaum@halkrausephoto.com Wed Jan 09 05:01:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXkU-0001eQ-8Y for atompub-archive@lists.ietf.org; Wed, 09 Jan 2008 05:01:26 -0500 Received: from [201.82.191.235] (helo=c952bfeb.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCXkR-0005EI-He for atompub-archive@lists.ietf.org; Wed, 09 Jan 2008 05:01:24 -0500 Received: from ricardo ([150.166.142.148] helo=ricardo) by c952bfeb.virtua.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1blrLR-000ORR-qU for atompub-archive@lists.ietf.org; Wed, 9 Jan 2008 08:00:08 -0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 9 Jan 2008 07:59:46 -0300 To: atompub-archive@lists.ietf.org From: "Traci nusbaum" Subject: ynnat Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.3 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Paula loves my new size, she doesn't know that the secret to it is V.P.X.L! http://thegoatsafake.com/ ynamolgi yomiki yrkesliv yrrem-en yosegak ynnehlic ynrap yrbihpma yrrefsda yressu yllaryg yokomizo From owner-atom-syntax@mail.imc.org Thu Jan 10 18:28:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6ol-0003hD-JT for atompub-archive@lists.ietf.org; Thu, 10 Jan 2008 18:28:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD6ol-0001MV-0i for atompub-archive@lists.ietf.org; Thu, 10 Jan 2008 18:28:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ANDFaj080394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2008 16:13:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ANDFGq080393; Thu, 10 Jan 2008 16:13:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ANDDB4080386 for ; Thu, 10 Jan 2008 16:13:14 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ANDDM2022581 for ; Thu, 10 Jan 2008 23:13:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUG00801AYQY100@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Thu, 10 Jan 2008 16:13:13 -0700 (MST) Received: from [192.168.102.101] (d154-20-170-13.bchsia.telus.net [154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUG00ANUB5N4G30@mail-amer.sun.com>; Thu, 10 Jan 2008 16:13:01 -0700 (MST) Date: Thu, 10 Jan 2008 15:12:52 -0800 From: Tim Bray Subject: Re: POST for an exisiting id? In-reply-to: <20080102200933.1291861785@smtp.haun-online.de> To: Dirk Haun Cc: Atom Syntax Message-id: <7E264426-8CE2-4357-88B8-6F6DCDF64DA3@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.915) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20080102200933.1291861785@smtp.haun-online.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Jan 2, 2008, at 12:09 PM, Dirk Haun wrote: > Apologies if I'm missing anything obvious, but I'm just sitting here > brooding over an Atom Protocol Exerciser Report and wondering "what > does > it want from me?" > > The APE's Mini One / Mini Two test apparently POSTs a second entry for > an already existing one (with the same id). Since RFC5023 states that > POST is for creation and PUT is for modification, I'm wondering what > to > do in that situation. Oh hell yes, that's a bug. Foo. Apparently enough server implementations ignore client-provided IDs that nobody noticed before. I don't think that what the Ape's doing is strictly forbidden by the RFC, but it's clearly bad practice and a server would definitely be within its rights in throwing the dupe-ID POSTs on the floor. Fixed, thanks. -Tim From Cervantesesh@tinklerlaw.com Fri Jan 11 22:24:45 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDWzF-0007Ez-Cv for atompub-archive@lists.ietf.org; Fri, 11 Jan 2008 22:24:45 -0500 Received: from [219.131.68.66] (helo=[219.131.68.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDWzE-0001U6-Og for atompub-archive@lists.ietf.org; Fri, 11 Jan 2008 22:24:45 -0500 Received: from jiang ([172.132.152.51] helo=jiang) by [219.131.68.66] ( sendmail 8.13.3/8.13.1) with esmtpa id 1BSJkp-000MZD-ef for atompub-archive@lists.ietf.org; Sat, 12 Jan 2008 11:25:06 +0800 Message-ID: <15F123F5.F801FA1F@tinklerlaw.com> Date: Sat, 12 Jan 2008 11:24:42 +0800 From: "gggg Cervantes" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: teichman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Herbal remedies that work like clockwork, your dick will grow long http://cranfishes.com/ From Gaming-Conners@cygnusx-1.com Sat Jan 12 19:15:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDqVY-0003gu-JO for atompub-archive@lists.ietf.org; Sat, 12 Jan 2008 19:15:24 -0500 Received: from auh-as31782.alshamil.net.ae ([217.164.75.32] helo=[38.99.101.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDqVX-0006Vh-Ko for atompub-archive@lists.ietf.org; Sat, 12 Jan 2008 19:15:24 -0500 Received: by 10.2.95.50 with SMTP id rbJmLkIRQCHyp; Sun, 13 Jan 2008 04:15:35 +0400 (GMT) Received: by 192.168.159.69 with SMTP id szAcKdAmFeOyXM.5866241075186; Sun, 13 Jan 2008 04:15:33 +0400 (GMT) Message-ID: <000b01c85579$682e7ce0$85656326@desert0ff29471> From: "Gaming Conners" To: Subject: tlmmevek Date: Sun, 13 Jan 2008 04:15:30 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8559A.EF401CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0006_01C8559A.EF401CE0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Permanant gains in length and thickness to your manhood, guaranteed. = http://euvihrphrs.com/ ------=_NextPart_000_0006_01C8559A.EF401CE0 Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0006_01C8559A.EF401CE0-- From natkrystek@normalcommunications.com Sun Jan 13 15:05:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE95C-00050P-Lj for atompub-archive@lists.ietf.org; Sun, 13 Jan 2008 15:05:26 -0500 Received: from host68-59-dynamic.180-80-r.retail.telecomitalia.it ([80.180.59.68] helo=host213-142-dynamic.11-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE95B-0005w2-Or for atompub-archive@lists.ietf.org; Sun, 13 Jan 2008 15:05:26 -0500 Received: by 10.83.222.231 with SMTP id ejfECLqwXgjCt; Sun, 13 Jan 2008 21:05:34 +0100 (GMT) Received: by 192.168.13.214 with SMTP id QMEztpZRPZTfkW.1092160042153; Sun, 13 Jan 2008 21:05:32 +0100 (GMT) Message-ID: <000501c8561f$a53bbe30$d58e0b4f@acer0625653e11> From: "nat krystek" To: Subject: lefatsdu Date: Sun, 13 Jan 2008 21:05:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C85628.07002630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 080112-0, 12/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.5 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0004_01C85628.07002630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Millions of dollars spent on research, and finally a penis lengthening = product that works. http://www.vnieennv.com/ ------=_NextPart_000_0004_01C85628.07002630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Millions of dollars spent on research, and = finally a=20 penis lengthening product that works. http://www.vnieennv.com/
------=_NextPart_000_0004_01C85628.07002630-- From Earley@elastomaniac.com Mon Jan 14 08:13:43 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEP8J-0005AR-AN for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 08:13:43 -0500 Received: from [85.105.121.73] (helo=dsl.static.85-105-31049.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEP8H-0000bG-Ty for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 08:13:42 -0500 Received: from masaaaa ([185.180.64.42]:10809 "EHLO masaaaa" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dsl.static.85-105-31049.ttnet.net.tr with ESMTP id S22XADMMFJDBISCT (ORCPT ); Mon, 14 Jan 2008 15:14:07 +0200 Message-ID: <000901c856af$47c668f0$49796955@masaaaa> From: "Orlando Earley" To: Subject: parbleu Date: Mon, 14 Jan 2008 15:13:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C856C0.0B4F38F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0009_01C856C0.0B4F38F0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable She loves my new size, big and long phallus is what she loves. = http://www.cnohroha.com/ ------=_NextPart_000_0009_01C856C0.0B4F38F0 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
She loves my new size, big and long phallus is what = she=20 loves. http://www.cnohroha.com/ ------=_NextPart_000_0009_01C856C0.0B4F38F0-- From owner-atom-syntax@mail.imc.org Mon Jan 14 10:12:41 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEQzR-00060l-T1 for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 10:12:41 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEQzR-0005Ze-7e for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 10:12:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0EER8L0016557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 07:27:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0EER8gR016556; Mon, 14 Jan 2008 07:27:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0EER5wk016550 for ; Mon, 14 Jan 2008 07:27:07 -0700 (MST) (envelope-from james.abley@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so903929mue.2 for ; Mon, 14 Jan 2008 06:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=RtpjzB44tujfRm9eYy30zb9p+QO2hYqjTkWYxOOx3vU=; b=whCuRXgNRtxBR0siKOZWMny63MSfhHEgBSI4uO5yVZv6Zn2xurST9vptHj2BFDgn26MpWXQYfGS53ofK1S2gGlK5eDarjpS7aRAzZByQTfMwlBu6ky0OT4EcW4Fp27eJOVJTEnhqv2961WSieXhq767EqNwgQq0V27axQQ7Q1hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DEkd7dqu4uOBLT/MRVjh8qT/B0RXWrZuD6XXDz6CP6PvT+ePLPOwRf8T9QnNQKJo+FkQgmlxU1TrvDD52jDOMVEnxEpEp9x7SUdQuhtI8WPn1nzXIKaEQjRQ0bL9/1Soo3pef2tKhCrQFwaVDyuWprsgwLaSc20fLq6AKBf2t+0= Received: by 10.78.81.20 with SMTP id e20mr7291102hub.60.1200320824904; Mon, 14 Jan 2008 06:27:04 -0800 (PST) Received: by 10.78.143.17 with HTTP; Mon, 14 Jan 2008 06:27:04 -0800 (PST) Message-ID: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> Date: Mon, 14 Jan 2008 14:27:04 +0000 From: "James Abley" To: atom-syntax@imc.org Subject: Atom feed design for a variety of media types MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi, The background for this request is that my company helps our partners deliver content on mobile internet platforms. We are trying to guide our partners into producing a common feed format that can be easily re-purposed and doesn't require specialist tools to handle. I'm trying to define a feed format for content which will be potentially produced by a variety of producers (news agencies, games companies, audio file producers and video producers as a starting point). The initial use case is purely for news, games and audio, so I'm dealing with multiple content types of media items. Atom is my own preferred choice (interop, tool support, etc) rather than anything else, so I've been trying to match my gut feel about how to implement this with what I've been reading in the archives for this list. My initial problem - meta-data ------------------------------------------- I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which should cover that. Otherwise, I'd need to introduce something similar to that module, which covers the shortfall. Or should I be using RDF or Dublin Core? Any experience or suggestions with this? Next problem - content expiry ------------------------------------------- Predominantly I think this is required for news agencies, so that they have control over what gets displayed downstream. My initial ideas, seemingly confirmed by the archives, are for one of the following: 1. A separate feed, the semantics of which are understood to indicate content expiry / deletion. 2. Tombstones. 3. Expiry explicitly indicated on feed items, again with an extension element / attribute, or RDF or Dublin Core. I think that the Tombstone discussion is going to go on for a while, and I'm quite comfortable with the idea of the first choice, unless anyone violently disagrees. Final problem (for now!) - editorial control / lead articles ------------------------------------------------------------------------------- Certain content producers have indicated that they need to be able to define importance on a feed entry; e.g. the story about the US election should be treated as the lead story, and the story about someone's lost dog is the "...and finally..." story that we can put at the bottom of a page. I haven't seen anything in core Atom about this, so maybe it's the extension element, or RDF or Dublin Core route again? Related subject - having multiple images for an item, with different semantics on the images; e.g. this one is the image related to the story subject matter; e.g. picture of Presidential candidate; this one is the headshot of the columnist that authored the story. For that, along with the extension element / RDF / Dublin Core options, I have the added choice of using a (non-official) link relation extension. This is where I'm least sure of what the right thing to do would be. James Snell recently blogged about proposing to OSCON a session on designing Atom extensions. I need it a little earlier than I thought! Cheers, James [1] http://search.yahoo.com/mrss [2] http://www.snellspace.com/wp/?p=848 From owner-atom-syntax@mail.imc.org Mon Jan 14 11:14:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JERxb-0007lB-RH for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 11:14:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JERxZ-0006ya-Hr for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 11:14:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0EFvWj6024607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 08:57:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0EFvW1D024606; Mon, 14 Jan 2008 08:57:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0EFvVE0024600 for ; Mon, 14 Jan 2008 08:57:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0506.google.com with SMTP id n1so895208nzf.4 for ; Mon, 14 Jan 2008 07:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=SN3+FL07ezMO7ZSSgfhsNQdw9d7vIUhhHblq55GEAa8=; b=bcbvpc6iLJ30Xs0sU/xRVrxVyw7+VwebG+FIVMIStm1eBnwxqzl455TJuMolESzvXtewiaD62gMQ2w6v/MpjOuKgioohllPd5M6PC0e73hcHXK9hqhbQLa2ofJ+EcNDnFdVIf8Gqycs/6LHo8uwbD3NGPLqB3IOK02VoYSKallA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=wTqO9/3MjXitaYKFClQHAzfvDgTQNWwqwm1pnDhKXSMu2dYLXJjCs2dB7BaWtIRNH83ZRF5WvDMsRN7f2c6RibgdFwGC5TQ/db3I3e6nHkZ5wubHDElqY92gAfLN8iZnHm52PLkhlXmNtYce0WU66ZakG2WzKnbQBGmMPC2c5Ss= Received: by 10.141.68.12 with SMTP id v12mr3893626rvk.111.1200326250726; Mon, 14 Jan 2008 07:57:30 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id f34sm8953525rvb.3.2008.01.14.07.57.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jan 2008 07:57:30 -0800 (PST) Message-ID: <478B8667.4080904@gmail.com> Date: Mon, 14 Jan 2008 07:57:27 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James Abley CC: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> In-Reply-To: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 1.2 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 James Abley wrote: > Hi, > > The background for this request is that my company helps our partners > deliver content on mobile internet platforms. We are trying to guide > our partners into producing a common feed format that can be easily > re-purposed and doesn't require specialist tools to handle. > > I'm trying to define a feed format for content which will be > potentially produced by a variety of producers (news agencies, games > companies, audio file producers and video producers as a starting > point). The initial use case is purely for news, games and audio, so > I'm dealing with multiple content types of media items. > > Atom is my own preferred choice (interop, tool support, etc) rather > than anything else, so I've been trying to match my gut feel about how > to implement this with what I've been reading in the archives for this > list. > > My initial problem - meta-data > ------------------------------------------- > I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which > should cover that. Otherwise, I'd need to introduce something similar > to that module, which covers the shortfall. Or should I be using RDF > or Dublin Core? Any experience or suggestions with this? > I've seen the both the Yahoo and iTunes extensions being used. I don't believe there is any one approach that would be recommended over the others. > Next problem - content expiry > ------------------------------------------- > Predominantly I think this is required for news agencies, so that they > have control over what gets displayed downstream. My initial ideas, > seemingly confirmed by the archives, are for one of the following: > > 1. A separate feed, the semantics of which are understood to indicate > content expiry / deletion. > 2. Tombstones. > 3. Expiry explicitly indicated on feed items, again with an extension > element / attribute, or RDF or Dublin Core. > > I think that the Tombstone discussion is going to go on for a while, > and I'm quite comfortable with the idea of the first choice, unless > anyone violently disagrees. > For the short term, #1 would likely be your best bet as it requires the least amount of invention and would be the easiest to migrate over to whatever the final tombstone approach becomes. > Final problem (for now!) - editorial control / lead articles > ------------------------------------------------------------------------------- > Certain content producers have indicated that they need to be able to > define importance on a feed entry; e.g. the story about the US > election should be treated as the lead story, and the story about > someone's lost dog is the "...and finally..." story that we can put at > the bottom of a page. > > I haven't seen anything in core Atom about this, so maybe it's the > extension element, or RDF or Dublin Core route again? > In Lotus Connections, we use atom:category elements for this. You could do so also, e.g. > Related subject - having multiple images for an item, with different > semantics on the images; e.g. this one is the image related to the > story subject matter; e.g. picture of Presidential candidate; this one > is the headshot of the columnist that authored the story. For that, > along with the extension element / RDF / Dublin Core options, I have > the added choice of using a (non-official) link relation extension. > > type="image/jpeg" /> > type="image/jpeg" /> > This is an excellent solution. > This is where I'm least sure of what the right thing to do would be. > James Snell recently blogged about proposing to OSCON a session on > designing Atom extensions. I need it a little earlier than I thought! > :-) - James > Cheers, > > James > > [1] http://search.yahoo.com/mrss > [2] http://www.snellspace.com/wp/?p=848 > > From owner-atom-syntax@mail.imc.org Mon Jan 14 14:48:28 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEVIK-00075g-BB for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 14:48:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEVII-0003se-I4 for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 14:48:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0EJYVHY043413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 12:34:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0EJYVXZ043411; Mon, 14 Jan 2008 12:34:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s16.bay0.hotmail.com (bay0-omc3-s16.bay0.hotmail.com [65.54.246.216]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0EJYUhI043404 for ; Mon, 14 Jan 2008 12:34:31 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.23]) by bay0-omc3-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jan 2008 11:34:30 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jan 2008 11:34:30 -0800 Message-ID: Received: from 85.211.254.81 by BAY141-DAV13.phx.gbl with DAV; Mon, 14 Jan 2008 19:34:28 +0000 X-Originating-IP: [85.211.254.81] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> Subject: Re: Atom feed design for a variety of media types Date: Mon, 14 Jan 2008 19:34:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 14 Jan 2008 19:34:30.0515 (UTC) FILETIME=[7B88BC30:01C856E4] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 James Abley wrote: > The background for this request is that my company helps our partners > deliver content on mobile internet platforms. We are trying to guide > our partners into producing a common feed format that can be easily > re-purposed and doesn't require specialist tools to handle. When you say "doesn't require specialist tools", does that mean you would like the feed to work with a typical feed reader? Or are you only worried about generating the feed with a general purpose tool (like say Abdera) but expect a specialist client to read the feed? If the former, I think you're going about this the wrong way. If the latter, you can ignore the rest of this message. > My initial problem - meta-data > ------------------------------------------- > I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which > should cover that. Exactly what kind of metadata do you need? If you just want to assign metadata to the feed entries then there's not that much that Yahoo Media gives you that isn't already in Atom (author, description, category, etc.). If your worry is that you need to include multiple media enclosures with each entry and want to provide separate metadata for each enclosure then you have much bigger problems. Support for multiple Atom enclosure links is fairly poor in current feed readers, but there is at least some support. Support for Yahoo media:content elements in Atom is non-existent (AFAIK). Your best bet for adding metadata to multiple enclosure elements would be as sub-elements of a standard atom:link element. That still requires a specialist client to view the metadata, but at least the media itself might be accessible to a general purpose reader. > Next problem - content expiry > ------------------------------------------- > Predominantly I think this is required for news agencies, so that they > have control over what gets displayed downstream. My initial ideas, > seemingly confirmed by the archives, are for one of the following: As long as those news agencies are aware that they really have no control over what gets displayed downstream. It doesn't matter what option you choose, nearly all general purpose feed readers will ignore it. The only hope of having any control like this would be with some form of encryption and a proprietary client (something like DIVX perhaps). > Final problem (for now!) - editorial control / lead articles > ------------------------------------------------------------------------------- > Certain content producers have indicated that they need to be able to > define importance on a feed entry; e.g. the story about the US > election should be treated as the lead story, and the story about > someone's lost dog is the "...and finally..." story that we can put at > the bottom of a page. I would go with a category element as James Snell suggested. That would at least have some value in a general purpose feed reader. > Related subject - having multiple images for an item, with different > semantics on the images; e.g. this one is the image related to the > story subject matter; e.g. picture of Presidential candidate; this one > is the headshot of the columnist that authored the story. For that, > along with the extension element / RDF / Dublin Core options, I have > the added choice of using a (non-official) link relation extension. I don't get what you're trying to do here. Why don't you just include the images in the (x)html of the content element, laid out in some way that would look good to a regular feed reader. If you need the metadata for use in a specialist client, come up with your own microformat (class attributes on the img elements). That should make it easy for the client to do a more fancy layout with CSS or even extract the images from the markup if necessary. Bottom line: if you want these feeds to be useful (not just barely functional) to a typical feed reader you need to be thinking how you can use standard Atom elements as much as possible. Extensions should be a last resort when all else has failed. Regards James From owner-atom-syntax@mail.imc.org Mon Jan 14 18:55:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEZ9B-0004KE-NQ for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 18:55:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEZ9A-0008T3-Nw for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 18:55:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ENi0CZ002727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 16:44:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ENi002002726; Mon, 14 Jan 2008 16:44:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ENhvk3002705 for ; Mon, 14 Jan 2008 16:43:59 -0700 (MST) (envelope-from james.abley@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so2636373fge.26 for ; Mon, 14 Jan 2008 15:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+varBXqukhMZHrWYaEr7dfy2t9RT1w0i3rSDHX/WQtU=; b=oS+fWCIOv0W1iTWAfpFko8/FZHPfoA41ugIgzcZ5FYDcSaWkQ3DdkQXXfMEYmZgDBcRUWs6VZTBbA+jNT4I/ATI6gk7yEOWVkpJheGwVxsBBCr2Yi59OpoR5Df6e8Y6samlW7BjN/iGEspoQx4LfwHjtbCP0kAsxj4wvC312Qzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Wkpe2CRIuAf51vTrtdJXqcLu6DlzL2mR0DhG91VhAswtFqs293/Tm2HMiB4wiT9Eb4G3Fna0Gpj5k5XKgn9V8ZWazywPtRENOyWEtZKSQMsWyh3Vp+YIYYqCs4wNRzsvPOz58VVbHwNhWwP5xINaKnBiA5z0IebqyQAUZNzImZA= Received: by 10.78.168.1 with SMTP id q1mr8313528hue.71.1200354237012; Mon, 14 Jan 2008 15:43:57 -0800 (PST) Received: by 10.78.143.17 with HTTP; Mon, 14 Jan 2008 15:43:56 -0800 (PST) Message-ID: <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> Date: Mon, 14 Jan 2008 23:43:56 +0000 From: "James Abley" To: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 On 14/01/2008, James Holderness wrote: > > James Abley wrote: > > The background for this request is that my company helps our partners > > deliver content on mobile internet platforms. We are trying to guide > > our partners into producing a common feed format that can be easily > > re-purposed and doesn't require specialist tools to handle. > > When you say "doesn't require specialist tools", does that mean you would > like the feed to work with a typical feed reader? Or are you only worried > about generating the feed with a general purpose tool (like say Abdera) but > expect a specialist client to read the feed? > > If the former, I think you're going about this the wrong way. If the latter, > you can ignore the rest of this message. My bad for not being clearer. It's pretty much the latter. It's a little strange. We have had a variety of clients with their own custom XML formats that we've imported, some that provide RSS 2.0 plus their own extension modules and some that don't have an existing feed and are amenable to our input in terms of how the feed is structured. For now, the feeds aren't consumed by typical feed readers - mainly just our importing application (which imports the content and processes it into a form suitable for display on mobile devices) and other partners' applications that wish to process the feed. In order to re-use our importer code-base as much as possible, we'd like to offer the same Atom-based suggestion to current and future clients. That has the obvious benefits for my company in that I only have to write one client using Abdera / suitable Java library and we can then get away from writing custom importers for each client. It also has the desirable property that our client ends up with a feed that should be useful in other contexts, and isn't irrevocably tied to our solution; i.e. the client doesn't feel locked in. One of our clients is talking about using this format with all of their partners in an industry sector, hence my desire to use open standards, re-use existing extensions and avoid any custom extensions as much as possible. I think (maybe incorrectly) that it's more likely to appeal to a wider community within that industry sector if it's open, standards-based rather than a proprietary format that maps to our internal binary data structures. In summary, we already have a client which will process these feeds. I'm trying to define a suitable format for our upstream partners to produce. > > > My initial problem - meta-data > > ------------------------------------------- > > I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which > > should cover that. > > Exactly what kind of metadata do you need? If you just want to assign > metadata to the feed entries then there's not that much that Yahoo Media > gives you that isn't already in Atom (author, description, category, etc.). > If your worry is that you need to include multiple media enclosures with > each entry and want to provide separate metadata for each enclosure then you > have much bigger problems. Maybe metadata is a bit misleading. I view it as metadata, but it's really just the attributes of the media entity. For images, this may be height, width, colour depth, etc. For video, this could be audio bitrate, video bitrate, frames per second, duration, etc. We could try extracting that ourselves, or we can rely on the author of the media entity knowing what it is and setting the corresponding attributes in the feed. > > Support for multiple Atom enclosure links is fairly poor in current feed > readers, but there is at least some support. Support for Yahoo media:content > elements in Atom is non-existent (AFAIK). Your best bet for adding metadata > to multiple enclosure elements would be as sub-elements of a standard > atom:link element. That still requires a specialist client to view the > metadata, but at least the media itself might be accessible to a general > purpose reader. That's what my current draft looks like, so colour me happy. There are typically multiple versions of the same media entity, e.g the lost dog story video; provided in different formats to ensure good coverage of target client devices. Alternatively, there may only be a single version, and we produce lots of different versions as part of the import process. > > > Next problem - content expiry > > ------------------------------------------- > > Predominantly I think this is required for news agencies, so that they > > have control over what gets displayed downstream. My initial ideas, > > seemingly confirmed by the archives, are for one of the following: > > As long as those news agencies are aware that they really have no control > over what gets displayed downstream. It doesn't matter what option you > choose, nearly all general purpose feed readers will ignore it. The only > hope of having any control like this would be with some form of encryption > and a proprietary client (something like DIVX perhaps). > > > Final problem (for now!) - editorial control / lead articles > > ------------------------------------------------------------------------------- > > Certain content producers have indicated that they need to be able to > > define importance on a feed entry; e.g. the story about the US > > election should be treated as the lead story, and the story about > > someone's lost dog is the "...and finally..." story that we can put at > > the bottom of a page. > > I would go with a category element as James Snell suggested. That would at > least have some value in a general purpose feed reader. > > > Related subject - having multiple images for an item, with different > > semantics on the images; e.g. this one is the image related to the > > story subject matter; e.g. picture of Presidential candidate; this one > > is the headshot of the columnist that authored the story. For that, > > along with the extension element / RDF / Dublin Core options, I have > > the added choice of using a (non-official) link relation extension. > > I don't get what you're trying to do here. Why don't you just include the > images in the (x)html of the content element, laid out in some way that > would look good to a regular feed reader. If you need the metadata for use > in a specialist client, come up with your own microformat (class attributes > on the img elements). That should make it easy for the client to do a more > fancy layout with CSS or even extract the images from the markup if > necessary. > > Bottom line: if you want these feeds to be useful (not just barely > functional) to a typical feed reader you need to be thinking how you can use > standard Atom elements as much as possible. Extensions should be a last > resort when all else has failed. > > Regards > James > > Thanks for your comments - very useful. I should have made my position clearer. Cheers, James From owner-atom-syntax@mail.imc.org Mon Jan 14 21:53:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEbvE-0003BK-Lm for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 21:53:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEbvC-0002vo-R3 for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 21:53:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F2fROU016297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 19:41:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0F2fRWW016296; Mon, 14 Jan 2008 19:41:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F2fOkJ016289 for ; Mon, 14 Jan 2008 19:41:26 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=dsX6U/Iwek+Tslt+5JjrhAhuUJQFGgSZM/glpbK/mxQHKOVLr/3pM HM+g2n9wHVb7scsEDMUVRcJLs1pnAHSO4JawxlBOYN4TDX0d0iCDy 7RU8VeMg3zOzN7jqJrh17CVoKzQzyK52W27ru1W0VOGeJqJ1huFcX hFnhEugPMUaI=; Received: from wb8-a.mail.utexas.edu ([128.83.126.148]) by ironmaiden.mail.utexas.edu with ESMTP; 14 Jan 2008 20:41:23 -0600 Received: (qmail 43973 invoked from network); 15 Jan 2008 02:41:23 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb8.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 15 Jan 2008 02:41:23 -0000 Date: Mon, 14 Jan 2008 20:41:23 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James Abley cc: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 On Mon, 14 Jan 2008, James Abley wrote: > > Maybe metadata is a bit misleading. I view it as metadata, but it's > really just the attributes of the media entity. For images, this may > be height, width, colour depth, etc. For video, this could be audio > bitrate, video bitrate, frames per second, duration, etc. We could try > extracting that ourselves, or we can rely on the author of the media > entity knowing what it is and setting the corresponding attributes in > the feed. > >> >> Support for multiple Atom enclosure links is fairly poor in current feed >> readers, but there is at least some support. Support for Yahoo media:content >> elements in Atom is non-existent (AFAIK). Your best bet for adding metadata >> to multiple enclosure elements would be as sub-elements of a standard >> atom:link element. That still requires a specialist client to view the >> metadata, but at least the media itself might be accessible to a general >> purpose reader. > > That's what my current draft looks like, so colour me happy. There are > typically multiple versions of the same media entity, e.g the lost dog > story video; provided in different formats to ensure good coverage of > target client devices. Alternatively, there may only be a single > version, and we produce lots of different versions as part of the > import process. > This is the same use case I am facing (digital image/video/audio/document library to be used in higher ed.). And figuring out metadata for multiple media entities is the last piece of the puzzle for using Atom. I had gone with a custom "microformat" xhtml to be included in the content for the media but encoding metadata using classes was getting kludgy. So...does this seem like a reasonable approach: 120 120 123 128 e18d8047a12bac8274e018dc70cb7d39 123 128 stereo 2e6e63a97c1cbcd4741489849f7e4ab8 This, too, is for a custom application (I am the consumer and publisher) but potential for reuse and the desire to create a sane design are highly desired. (I, too, need to attend a James Snell session on creating atom extensions!). -peter keane daseproject.org From owner-atom-syntax@mail.imc.org Mon Jan 14 22:36:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEcbG-0001ji-GI for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 22:36:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEcbG-0003QX-0y for atompub-archive@lists.ietf.org; Mon, 14 Jan 2008 22:36:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F3PoDq019767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 20:25:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0F3Po4k019766; Mon, 14 Jan 2008 20:25:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F3PlNr019758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jan 2008 20:25:50 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.166.17]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id AE0FE23E458 for ; Mon, 14 Jan 2008 22:25:46 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" Subject: RE: Atom feed design for a variety of media types Date: Mon, 14 Jan 2008 19:25:47 -0800 Message-ID: <002701c85726$527ac350$0201a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchWui0QLqTm1Z5pQ06fhBHy2GYtogAaQPWwAADHCmA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 James Abley wrote: > My initial problem - meta-data > ------------------------------------------- > I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which > should cover that. Otherwise, I'd need to introduce something similar > to that module, which covers the shortfall. Or should I be using RDF > or Dublin Core? Any experience or suggestions with this? Media RSS seems really verbose to be sending to a mobile phone. I think it makes sense to send the Media RSS-annotated feed to the gateway, have the gateway choose alternatives based on the phone's capabilities, and then send a compact, customized feed to the handset. > Next problem - content expiry > ------------------------------------------- > Predominantly I think this is required for news agencies, so that they > have control over what gets displayed downstream. > My initial ideas, seemingly confirmed by the archives, are for one of > the following: > > 1. A separate feed, the semantics of which are understood to indicate > content expiry / deletion. > 2. Tombstones. > 3. Expiry explicitly indicated on feed items, again with an extension > element / attribute, or RDF or Dublin Core. > > I think that the Tombstone discussion is going to go on for a while, > and I'm quite comfortable with the idea of the first choice, unless > anyone violently disagrees. If you are in control of all the clients, then I would recommend using FeedSync. That will allow you to easily support bidirectional (actually n-way) syncing if/when you need it. Conversely, if you need to support current Atom clients, then I recommend against FeedSync. I think #1 is the worst idea because it doubles the number of feeds that the handset needs to poll. When I was doing stuff with handheld devices, I had to reduce network traffic as much as possible, because the average user has a really bad internet connection on his phone. - Brian From owner-atom-syntax@mail.imc.org Tue Jan 15 00:40:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEeXh-00086Y-DG for atompub-archive@lists.ietf.org; Tue, 15 Jan 2008 00:40:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEeXg-0005Rz-SN for atompub-archive@lists.ietf.org; Tue, 15 Jan 2008 00:40:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F5TWKD027468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 22:29:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0F5TWWS027467; Mon, 14 Jan 2008 22:29:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F5TVOm027460 for ; Mon, 14 Jan 2008 22:29:31 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so518011anc.44 for ; Mon, 14 Jan 2008 21:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=OGu1vWPBVKvsmkKZ94fPP9+jykC5aulYbxOhlOh4B08=; b=R5ZEWn0h5lOqiqbthaZUp+21xOPd4FANFsMSW1+sZWViSX3QAuhFt51FvAEK4zx0JRaFRDKvXQ3LzOpZi0TXUYBEG6gIfs55SSDKw271OyL6abiycIpNHivLuR/3FlDBlGhoSQPq5+3O61nvTCQZrZ6fLlJA27QNGAsjTbjObnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=xp7tZ1N7XCCi0ljL2VWJ3V+5Yi5ct0LTPk1FEqWFcLMNWKYylmNYYkdt5JE13edh1AgtGwaW6iC1YRZBmcktHlUOGbLrgAGbRAXwhOc/LZbq7LOj3OnOJxM5xOWingf/GoladEPkbQvjkhFwaK5JTNr1Zg2As0s9BoirpmBGNlw= Received: by 10.101.68.19 with SMTP id v19mr15952586ank.4.1200374970501; Mon, 14 Jan 2008 21:29:30 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 8sm7820321hsp.19.2008.01.14.21.29.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jan 2008 21:29:30 -0800 (PST) Message-ID: <478C44B7.3060908@gmail.com> Date: Mon, 14 Jan 2008 21:29:27 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Peter Keane CC: James Abley , atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca I had been involved in some discussions a while back geared towards working on a standard set of media extensions derived from the itunes and yahoo media extensions. Unfortunately, that work never progressed. Such work would certainly not be unwelcome. - James Peter Keane wrote: > > [snip] > This is the same use case I am facing (digital > image/video/audio/document library to be used in higher ed.). And > figuring out metadata for multiple media entities is the last piece of > the puzzle for using Atom. I had gone with a custom "microformat" xhtml > to be included in the content for the media but encoding metadata using > classes was getting kludgy. So...does this seem like a reasonable > approach: > > href="http://example.com/media/123_100.jpg" type="image/jpeg" > length="3452"> > 120 > 120 > > > type="video/quicktime" length="3434343"> > 123 > 128 > e18d8047a12bac8274e018dc70cb7d39 > > > type="audio/mpeg" length="34343"> > 123 > 128 > stereo > 2e6e63a97c1cbcd4741489849f7e4ab8 > > > This, too, is for a custom application (I am the consumer and publisher) > but potential for reuse and the desire to create a sane design are > highly desired. (I, too, need to attend a James Snell session on > creating atom extensions!). > > -peter keane > > daseproject.org > > From owner-atom-syntax@mail.imc.org Tue Jan 15 00:59:32 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEepg-0003ZC-T3 for atompub-archive@lists.ietf.org; Tue, 15 Jan 2008 00:59:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEepe-0005f7-Gn for atompub-archive@lists.ietf.org; Tue, 15 Jan 2008 00:59:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F5maHl029273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2008 22:48:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0F5madd029272; Mon, 14 Jan 2008 22:48:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0F5mZlf029266 for ; Mon, 14 Jan 2008 22:48:36 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=jPXw0pZ2YJQ+WkBSIUk4x0cKmAPXUnWvFpMDz7EdetFv6VeIY1I+j +NhG1liaWDgYQTUL4ByuHTPt/3uKGOiNOS5W/3O3CdsI3SXrOLjZS Ze3kdgLRiTIp5KM1Xn+lHkobWsCJHtJakWvbagRAcfZ+VSMzZ8TNe SN9zNTqLWN9g=; Received: from wb1-a.mail.utexas.edu ([128.83.126.134]) by ironman.mail.utexas.edu with ESMTP; 14 Jan 2008 23:48:35 -0600 Received: (qmail 97799 invoked from network); 15 Jan 2008 05:48:35 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb1.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 15 Jan 2008 05:48:35 -0000 Date: Mon, 14 Jan 2008 23:48:35 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: James Abley , atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: <478C44B7.3060908@gmail.com> Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 On Mon, 14 Jan 2008, James M Snell wrote: > I had been involved in some discussions a while back geared towards working > on a standard set of media extensions derived from the itunes and yahoo media > extensions. Unfortunately, that work never progressed. Such work would > certainly not be unwelcome. > > - James Absolutely. It would be a huge boon for the sort of work we are trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. A Media-rich Atom standard would be a no-brainer for that area (and with FeedSync or a FeedSync-type standard along with it, a very powerful platform indeed). Any thoughts on how such a process might be re-booted? -peter > > Peter Keane wrote: >> >> [snip] >> This is the same use case I am facing (digital >> image/video/audio/document library to be used in higher ed.). And >> figuring out metadata for multiple media entities is the last piece of >> the puzzle for using Atom. I had gone with a custom "microformat" xhtml >> to be included in the content for the media but encoding metadata using >> classes was getting kludgy. So...does this seem like a reasonable >> approach: >> >> > href="http://example.com/media/123_100.jpg" type="image/jpeg" >> length="3452"> >> 120 >> 120 >> >> >> > type="video/quicktime" length="3434343"> >> 123 >> 128 >> e18d8047a12bac8274e018dc70cb7d39 >> >> >> > type="audio/mpeg" length="34343"> >> 123 >> 128 >> stereo >> 2e6e63a97c1cbcd4741489849f7e4ab8 >> >> >> This, too, is for a custom application (I am the consumer and publisher) >> but potential for reuse and the desire to create a sane design are highly >> desired. (I, too, need to attend a James Snell session on creating atom >> extensions!). >> >> -peter keane >> >> daseproject.org >> >> > From lswaynie@enimoscow.ru Tue Jan 15 17:59:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEukM-00042F-So for atompub-archive@lists.ietf.org; Tue, 15 Jan 2008 17:59:06 -0500 Received: from [74.7.21.121] (helo=tugizs) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JEukL-00016J-Rq for atompub-archive@lists.ietf.org; Tue, 15 Jan 2008 17:59:06 -0500 Received: from qqtp ([38.89.159.167]) by tugizs (8.13.1/8.13.1) with SMTP id m0FN7XA3026153; Tue, 15 Jan 2008 17:07:33 -0600 Message-ID: <478D3C2A.8080105@enimoscow.ru> Date: Tue, 15 Jan 2008 17:05:14 -0600 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: become one of well-hung mates! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Urgent healthcare info http://ceqs.speakgas.com From marchesini@in.ey.com Tue Jan 15 18:00:18 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEulW-0006ad-4X for atompub-archive@megatron.ietf.org; Tue, 15 Jan 2008 18:00:18 -0500 Received: from [74.7.21.121] (helo=tugizs) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JEulV-00018E-O6 for atompub-archive@megatron.ietf.org; Tue, 15 Jan 2008 18:00:18 -0500 Received: from vaj ([76.86.202.189]) by tugizs (8.13.2/8.13.2) with SMTP id m0FNAVMZ026153; Tue, 15 Jan 2008 17:10:31 -0600 Message-ID: <478D3C72.7040800@in.ey.com> Date: Tue, 15 Jan 2008 17:06:26 -0600 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: atompub-archive@megatron.ietf.org Subject: Viaaaagrrrraaaa is your magic weapon Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 At the time you don't have to search for chemists at your region http://cgia.speeddegree.com From owner-atom-syntax@mail.imc.org Wed Jan 16 04:28:13 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF4ZB-0001Fx-TB for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 04:28:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF4ZA-0000dt-6d for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 04:28:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0G9Apkq057790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 02:10:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0G9ApHe057789; Wed, 16 Jan 2008 02:10:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0G9AnLl057781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Jan 2008 02:10:50 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.138] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id m0G9Aj6F005143 for ; Wed, 16 Jan 2008 03:10:49 -0600 Message-ID: <478DD7B3.8090705@defuze.org> Date: Wed, 16 Jan 2008 10:08:51 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 CC: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0G9Apkq057790 X-Spam-Score: 1.6 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Peter Keane a =E9crit : > > > > On Mon, 14 Jan 2008, James M Snell wrote: > >> I had been involved in some discussions a while back geared towards=20 >> working on a standard set of media extensions derived from the itunes=20 >> and yahoo media extensions. Unfortunately, that work never=20 >> progressed. Such work would certainly not be unwelcome. >> >> - James > > Absolutely. It would be a huge boon for the sort of work we are=20 > trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. =20 > A Media-rich Atom standard would be a no-brainer for that area (and=20 > with FeedSync or a FeedSync-type standard along with it, a very=20 > powerful platform indeed). > > Any thoughts on how such a process might be re-booted? I concur and I'd join such work if it existed. - Sylvain From hkumk@2gather.de Wed Jan 16 07:07:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF73h-0004fQ-EU for atompub-archive@megatron.ietf.org; Wed, 16 Jan 2008 07:07:53 -0500 Received: from [59.92.132.238] (helo=shxm) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JF73f-0003u4-Lh for atompub-archive@megatron.ietf.org; Wed, 16 Jan 2008 07:07:53 -0500 Received: from xjj ([60.109.233.79]) by shxm (8.13.3/8.13.3) with SMTP id m0G0BnEZ008196; Wed, 16 Jan 2008 05:41:49 +0530 Message-ID: <478D4B20.8040800@2gather.de> Date: Wed, 16 Jan 2008 05:39:04 +0530 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: atompub-archive@megatron.ietf.org Subject: Our Love is Free Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 I Would Dream http://71.60.40.210/ From owner-atom-syntax@mail.imc.org Wed Jan 16 11:13:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFAtk-0005Qp-BM for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 11:13:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFAtj-0001vk-U7 for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 11:13:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0GFtXiI092589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 08:55:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0GFtXxs092588; Wed, 16 Jan 2008 08:55:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0GFtSCa092559 for ; Wed, 16 Jan 2008 08:55:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so65582anc.44 for ; Wed, 16 Jan 2008 07:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=C6MXuqrLMD/uz3gUaBTBUS/VLsAXVzlToDYjSQcWA8A=; b=nJu2TQE4smdsqTsgqb+Kl8t7NiY0bnsNRo8IgLIrdUuw1wgc5YIvi3jJoR6LWDWA1i+j6Eayx6rlB5SSlBfPbdSKqoG5SOXieRvoQTKXIfXmSSkNwmMSYN4SlJeR4PvJ0VQPr1b6LWjGW6rvbSMJL6Pq9ja61F05tsNVzwQyudU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=oJlRcewQsLesQl2fkpWa4OycjT7e//t347ELTTsK6ZMiNZ0OV0F/wUMOSKyYcv8lbE8dF7rKGBCe0mzVbmiQCLLZ5ir5Y1CFgCTD1HevLz8xTxzLi5bZVJ8mhJZ9JXriEbCvmb5y30jvybGfHIcbovpZQxqoLi/GI/Pmm7GIync= Received: by 10.100.139.20 with SMTP id m20mr1922546and.102.1200498927743; Wed, 16 Jan 2008 07:55:27 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 52sm954280hsf.17.2008.01.16.07.55.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Jan 2008 07:55:26 -0800 (PST) Message-ID: <478E28EB.1070203@gmail.com> Date: Wed, 16 Jan 2008 07:55:23 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Sylvain Hellegouarch CC: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> In-Reply-To: <478DD7B3.8090705@defuze.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0GFtXiI092589 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f All it would really take are implementors willing to support the=20 extensions once they were defined and a group of individuals willing to=20 do the work to define them. I'm willing to help. - James Sylvain Hellegouarch wrote: >=20 > Peter Keane a =E9crit : >> >> >> >> On Mon, 14 Jan 2008, James M Snell wrote: >> >>> I had been involved in some discussions a while back geared towards=20 >>> working on a standard set of media extensions derived from the itunes= =20 >>> and yahoo media extensions. Unfortunately, that work never=20 >>> progressed. Such work would certainly not be unwelcome. >>> >>> - James >> >> Absolutely. It would be a huge boon for the sort of work we are=20 >> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. =20 >> A Media-rich Atom standard would be a no-brainer for that area (and=20 >> with FeedSync or a FeedSync-type standard along with it, a very=20 >> powerful platform indeed). >> >> Any thoughts on how such a process might be re-booted? >=20 > I concur and I'd join such work if it existed. >=20 > - Sylvain >=20 >=20 From owner-atom-syntax@mail.imc.org Wed Jan 16 19:45:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFIse-0005OP-M1 for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 19:45:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFIse-0006PI-80 for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 19:45:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H0X6Rg039552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 17:33:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H0X6Pl039551; Wed, 16 Jan 2008 17:33:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H0X54K039543 for ; Wed, 16 Jan 2008 17:33:06 -0700 (MST) (envelope-from james.abley@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so507615fge.26 for ; Wed, 16 Jan 2008 16:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=j7IhAjWSAyoL7tF1SRoQ7vlbo8/jAbqTwpGvqH3q+4c=; b=DCevvw0/ceh/KSqE+10ZE1LTAAOsy2S7VXM1JE3sV4t9TlPcd5cgjkShBkt/w2sFsXQJeMKlzKLGjK9IlHnQmpw7i/dJX3EqkdrHUdsiCqndIa27KXme96sbPjFNEjMMQoce2OqUJiv1yig85lg06Z9W8Ff1vBPhxo88gP6bxX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=xRJwi72cI4AIaGdnoSjcd7Tr3KFM6W9uupha+BDj6Pg88re02lWf/1w+x5yNGQma1u1lbJwEorGaLXVIqphFXQXv6D6P1n/6L9/3WVfq5pfJLGqNotsjdSXVj1mS3GapizwZH2rrjGoH+wjlSAQRfuCEN7lYn0gWoWF0B2p2dxQ= Received: by 10.78.168.1 with SMTP id q1mr1930740hue.76.1200529984171; Wed, 16 Jan 2008 16:33:04 -0800 (PST) Received: by 10.78.143.17 with HTTP; Wed, 16 Jan 2008 16:33:04 -0800 (PST) Message-ID: <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> Date: Thu, 17 Jan 2008 00:33:04 +0000 From: "James Abley" To: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: <478E28EB.1070203@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0H0X64K039546 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0H0X6Rg039552 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On 16/01/2008, James M Snell wrote: > > All it would really take are implementors willing to support the > extensions once they were defined and a group of individuals willing to > do the work to define them. I'm willing to help. > > - James > I'm wary of making commitments that I can't keep, having recently had to drop out of one community due to most of my spare hacking time being taken up with working at the startup that I'm currently with, but I'd like to take this forward if possible. Any suggestions for ways to do that? James > Sylvain Hellegouarch wrote: > > > > Peter Keane a =E9crit : > >> > >> > >> > >> On Mon, 14 Jan 2008, James M Snell wrote: > >> > >>> I had been involved in some discussions a while back geared towards > >>> working on a standard set of media extensions derived from the itun= es > >>> and yahoo media extensions. Unfortunately, that work never > >>> progressed. Such work would certainly not be unwelcome. > >>> > >>> - James > >> > >> Absolutely. It would be a huge boon for the sort of work we are > >> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. > >> A Media-rich Atom standard would be a no-brainer for that area (and > >> with FeedSync or a FeedSync-type standard along with it, a very > >> powerful platform indeed). > >> > >> Any thoughts on how such a process might be re-booted? > > > > I concur and I'd join such work if it existed. > > > > - Sylvain From owner-atom-syntax@mail.imc.org Wed Jan 16 22:44:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFLg3-0002ey-Oj for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 22:44:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFLg2-0000O0-5s for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 22:44:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H3W6b6055833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 20:32:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H3W6O2055832; Wed, 16 Jan 2008 20:32:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H3W5Oq055825 for ; Wed, 16 Jan 2008 20:32:05 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so112604anc.44 for ; Wed, 16 Jan 2008 19:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=4bxnY4YjSqPqBw9BcJ+VtaB/EoMBv3hFPHBWt4H2Szo=; b=auNhmxCxTuW/l/dcTygWAqvcofWKTrDTbHY4w4WKHn1Dj1R64dmS3T+N0wvaAHGVT8El8IGrizGmcnrMLo0JEbMPE1so6CI5rPhLNb5hb/QF6itJGJ59Myux0DNh6KBOydiULy+cL4a7MBY9kO8X/SSdEattTeAZjcDG+BamE3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=AnGliMzNk1+iPHX9S3y0RHgT6RduOkzso/obyzMnnWMAE9f0yMPOE9+6/s2yeJhLUIexLumZebfPAK5o/lCqwWFFNtHG5wyr8p3u/MQXWKwQTyTpQFLDnB/1CT+GKjVsBMmUfq/YsJyDAAmN1eA0r20whMMS9ml26Z2nCiqIoTg= Received: by 10.100.227.20 with SMTP id z20mr3310846ang.48.1200540724787; Wed, 16 Jan 2008 19:32:04 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 7sm1621222hsx.4.2008.01.16.19.32.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Jan 2008 19:32:04 -0800 (PST) Message-ID: <478ECC31.2060706@gmail.com> Date: Wed, 16 Jan 2008 19:32:01 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James Abley CC: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> In-Reply-To: <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0H3W6b6055833 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c The best place to start would be to start collecting as many use cases=20 as possible from folks who are writing actual code; documenting what=20 kinds of information need to be in the feeds and why. - James James Abley wrote: > On 16/01/2008, James M Snell wrote: >> All it would really take are implementors willing to support the >> extensions once they were defined and a group of individuals willing t= o >> do the work to define them. I'm willing to help. >> >> - James >> >=20 > I'm wary of making commitments that I can't keep, having recently had > to drop out of one community due to most of my spare hacking time > being taken up with working at the startup that I'm currently with, > but I'd like to take this forward if possible. Any suggestions for > ways to do that? >=20 > James >=20 >> Sylvain Hellegouarch wrote: >>> Peter Keane a =E9crit : >>>> >>>> >>>> On Mon, 14 Jan 2008, James M Snell wrote: >>>> >>>>> I had been involved in some discussions a while back geared towards >>>>> working on a standard set of media extensions derived from the itun= es >>>>> and yahoo media extensions. Unfortunately, that work never >>>>> progressed. Such work would certainly not be unwelcome. >>>>> >>>>> - James >>>> Absolutely. It would be a huge boon for the sort of work we are >>>> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. >>>> A Media-rich Atom standard would be a no-brainer for that area (and >>>> with FeedSync or a FeedSync-type standard along with it, a very >>>> powerful platform indeed). >>>> >>>> Any thoughts on how such a process might be re-booted? >>> I concur and I'd join such work if it existed. >>> >>> - Sylvain >=20 >=20 From owner-atom-syntax@mail.imc.org Wed Jan 16 22:57:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFLsV-0006Of-A4 for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 22:57:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFLsU-0000WM-6s for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 22:57:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H3kHXh056720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 20:46:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H3kHsf056719; Wed, 16 Jan 2008 20:46:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H3kG3t056705 for ; Wed, 16 Jan 2008 20:46:17 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=ACUfpdJa91M/B11Yj7zWRvFXRU7M+PkqwF6bIm4vKlL7FpDOnLVeV z/W6h2G5egxbk0j9WZUSvz/bWIsfGLDZ7JmOYUCGyJIcjbx6Kmfrv AZsQ/6xgpJHGvRg894AMoKBy6PQDGYrHjDE9Loq3f2zFDvMT6tRHO C6bD5rYr5sC0=; Received: from wb9-a.mail.utexas.edu ([128.83.126.150]) by ironman.mail.utexas.edu with ESMTP; 16 Jan 2008 21:46:16 -0600 Received: (qmail 82730 invoked from network); 17 Jan 2008 03:46:16 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb9.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 17 Jan 2008 03:46:16 -0000 Date: Wed, 16 Jan 2008 21:46:16 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James Abley cc: "'Atom-Syntax'" Subject: Re: Atom feed design for a variety of media types In-Reply-To: <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-342172046-1200541576=:27211" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-342172046-1200541576=:27211 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0H3kHXh056720 A use-case, if it's of interest: We have an online digital library=20 application, which contains images (jpg,png,gif,tiff), also PDFs, audio=20 files (mp3,wav), video (mpeg4, etc). It's widely used here at UT Austin,=20 mostly for instructional purposes, but also for content-managing media=20 rich web sites [0]. It uses Atom extensively for moving data around and=20 for archiving collections. I typically get EXIF data from jpegs, id3v2 medatadata from mp3s, and IPT= C data from images when possible. I can use the content element in Atom to capture metadata about the primary media file, but it's that metadata tha= t varies per media file that I need to deal with (height, width, bitrate, stereo/mono, aspect ratio, md5 hash, etc.) in atom:link. Yahoo's Media RSS Module [1] seems to do most of what I need, and perhaps just using that is the best option. There was a need expressed some time back for the Atom group to address these media file issues [2] and again in the current thread. It strikes me that any of: 1. saying that using Yahoo Media RSS is a "best practice", 2. "porting" Yahoo Media RSS to a more Atom-like syntax and implementing that, 3. doing something else entirely -- would be fine. I really like the idea of the atom "link" element being the appropriate=20 starting point and working on the best set of "rel" values and a set of=20 agreed-upon child elements (based on Yahoo Media RSS). Of course, Yahoo=20 Media RSS has the idea of a "media group" (i.e. a set of files that are=20 different versions of the same thing) which I really like and which=20 should, I think, be handled. I'm not 100% sure what all needs to be done= =20 to begin defining extensions, but I would be glad to take a stab at=20 "porting" Yahoo Media RSS to an atom-like syntax for others to comment on= =20 if folks think that'd be a useful exercise. One more point: ours is a "closed" system in many ways, so it doesn't=20 really matter what we do, but time and again I have folks wanting to=20 repurpose their materials (usually "podcasting", but other ways as well).= =20 Being able to share collections externally and/or to ingest collections=20 born elsewhere would be a tremendous benefit. --Peter Keane [0] http://elucy.org [1] http://search.yahoo.com/mrss [2] http://www.imc.org/atom-syntax/mail-archive/msg11813.html On Thu, 17 Jan 2008, James Abley wrote: > > On 16/01/2008, James M Snell wrote: >> >> All it would really take are implementors willing to support the >> extensions once they were defined and a group of individuals willing t= o >> do the work to define them. I'm willing to help. >> >> - James >> > > I'm wary of making commitments that I can't keep, having recently had > to drop out of one community due to most of my spare hacking time > being taken up with working at the startup that I'm currently with, > but I'd like to take this forward if possible. Any suggestions for > ways to do that? > > James > >> Sylvain Hellegouarch wrote: >>> >>> Peter Keane a =E9crit : >>>> >>>> >>>> >>>> On Mon, 14 Jan 2008, James M Snell wrote: >>>> >>>>> I had been involved in some discussions a while back geared towards >>>>> working on a standard set of media extensions derived from the itun= es >>>>> and yahoo media extensions. Unfortunately, that work never >>>>> progressed. Such work would certainly not be unwelcome. >>>>> >>>>> - James >>>> >>>> Absolutely. It would be a huge boon for the sort of work we are >>>> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. >>>> A Media-rich Atom standard would be a no-brainer for that area (and >>>> with FeedSync or a FeedSync-type standard along with it, a very >>>> powerful platform indeed). >>>> >>>> Any thoughts on how such a process might be re-booted? >>> >>> I concur and I'd join such work if it existed. >>> >>> - Sylvain > --0-342172046-1200541576=:27211-- From owner-atom-syntax@mail.imc.org Wed Jan 16 23:17:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMCU-0001eZ-Iw for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 23:17:58 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFMCT-0000kw-SM for atompub-archive@lists.ietf.org; Wed, 16 Jan 2008 23:17:58 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H45jsX057692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 21:05:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H45jl2057691; Wed, 16 Jan 2008 21:05:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H45ifa057683 for ; Wed, 16 Jan 2008 21:05:44 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=ZOAmuWoxZOEHr2ITN5x+U9xEaaGwFnE84cH+v6VXR7Osnj0Fq1lry xyLf8vUdJR6HMhGRBIr5KYJT/n4PRnG/unpA27OvGUUocAxNMBf68 bp6B0BRHFv+ft6ope7hflb052mEhe3Vlwv89+WjCOmiyf6FGXD2Ux 1vuTSsC43hsM=; Received: from wb1-a.mail.utexas.edu ([128.83.126.134]) by ironmaiden.mail.utexas.edu with ESMTP; 16 Jan 2008 22:05:43 -0600 Received: (qmail 27142 invoked from network); 17 Jan 2008 04:05:43 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb1.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 17 Jan 2008 04:05:43 -0000 Date: Wed, 16 Jan 2008 22:05:43 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James M Snell cc: James Abley , atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: <478ECC31.2060706@gmail.com> Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> <478ECC31.2060706@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1930482619-1200542743=:27211" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1930482619-1200542743=:27211 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0H45jsX057692 One thing I wanted to add about the use case I described & this effort.=20 For me the goal is: 1. to come up with an agreed upon way to record=20 metadata about media files, and 2. to define, even if implicitly, when=20 a set of media files is appropriately attached to one entry and when each= =20 of those media files should really have it's own entry (i.e., if you are=20 simply recreating the same elements of the atom entry as children of=20 atom:link, the media file ought to have its own entry). As a librarian I have seen these sorts of conversation lead to fascinatin= g=20 but never-ending philosophizing [0]. I greatly appreciate the Atom=20 communities' track record of deciding what is the "simplest thing that'll= =20 work" and leaving it at that (plus extensibility, of course). --peter keane [0] http://www.loc.gov/cds/FRBR.html On Wed, 16 Jan 2008, James M Snell wrote: > > The best place to start would be to start collecting as many use cases = as=20 > possible from folks who are writing actual code; documenting what kinds= of=20 > information need to be in the feeds and why. > > - James > > James Abley wrote: >> On 16/01/2008, James M Snell wrote: >>> All it would really take are implementors willing to support the >>> extensions once they were defined and a group of individuals willing = to >>> do the work to define them. I'm willing to help. >>>=20 >>> - James >>>=20 >>=20 >> I'm wary of making commitments that I can't keep, having recently had >> to drop out of one community due to most of my spare hacking time >> being taken up with working at the startup that I'm currently with, >> but I'd like to take this forward if possible. Any suggestions for >> ways to do that? >>=20 >> James >>=20 >>> Sylvain Hellegouarch wrote: >>>> Peter Keane a =E9crit : >>>>>=20 >>>>>=20 >>>>> On Mon, 14 Jan 2008, James M Snell wrote: >>>>>=20 >>>>>> I had been involved in some discussions a while back geared toward= s >>>>>> working on a standard set of media extensions derived from the itu= nes >>>>>> and yahoo media extensions. Unfortunately, that work never >>>>>> progressed. Such work would certainly not be unwelcome. >>>>>>=20 >>>>>> - James >>>>> Absolutely. It would be a huge boon for the sort of work we are >>>>> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. >>>>> A Media-rich Atom standard would be a no-brainer for that area (and >>>>> with FeedSync or a FeedSync-type standard along with it, a very >>>>> powerful platform indeed). >>>>>=20 >>>>> Any thoughts on how such a process might be re-booted? >>>> I concur and I'd join such work if it existed. >>>>=20 >>>> - Sylvain >>=20 >>=20 > --0-1930482619-1200542743=:27211-- From edwin719@dmv.org Thu Jan 17 00:08:33 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFMzR-0007hi-7Y for atompub-archive@megatron.ietf.org; Thu, 17 Jan 2008 00:08:33 -0500 Received: from [89.123.121.195] (helo=sqdgcd) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFMzO-0001M5-PK for atompub-archive@megatron.ietf.org; Thu, 17 Jan 2008 00:08:33 -0500 Received: from wrv ([205.142.199.130]) by sqdgcd (8.13.3/8.13.3) with SMTP id m0H5B2uv030910; Thu, 17 Jan 2008 07:11:02 +0200 Message-ID: <478EE2CC.4070301@dmv.org> Date: Thu, 17 Jan 2008 07:08:28 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: atompub-archive@megatron.ietf.org Subject: I Dream of you Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Sending You All My Love http://202.247.99.251/ From owner-atom-syntax@mail.imc.org Thu Jan 17 03:07:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPmi-00021M-Sx for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 03:07:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFPmh-0003u2-7m for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 03:07:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H7sQbg070580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 00:54:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H7sQDC070579; Thu, 17 Jan 2008 00:54:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s20.bay0.hotmail.com (bay0-omc1-s20.bay0.hotmail.com [65.54.246.92]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H7sQku070564 for ; Thu, 17 Jan 2008 00:54:26 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.13]) by bay0-omc1-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jan 2008 23:54:25 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Jan 2008 23:54:25 -0800 Message-ID: Received: from 85.211.254.81 by BAY141-DAV3.phx.gbl with DAV; Thu, 17 Jan 2008 07:54:21 +0000 X-Originating-IP: [85.211.254.81] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "'Atom-Syntax'" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> Subject: Re: Atom feed design for a variety of media types Date: Thu, 17 Jan 2008 07:54:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 17 Jan 2008 07:54:25.0464 (UTC) FILETIME=[2DCFDB80:01C858DE] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Peter Keane wrote: > It strikes me that any of: 1. saying that using > Yahoo Media RSS is a "best practice", 2. "porting" Yahoo Media RSS to a > more Atom-like syntax and implementing that, 3. doing something else > entirely -- would be fine. It's hard to recommend the Yahoo module as a best practice when the spec has been broken for years, and Yahoo is apparently incapable of fixing it, despite having know of the problem for more than 6 months now (at least). Also, it would nice if whatever you did still worked (albeit with less functionality) with clients that weren't aware of your extensions. That means using a basic Atom enclosure link as your starting point, and then adding any extensions on top of that. Regards James From owner-atom-syntax@mail.imc.org Thu Jan 17 04:39:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFRDZ-0006z4-4j for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 04:39:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFRDX-0005b9-KK for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 04:39:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H9RQ28080201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 02:27:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H9RQsV080200; Thu, 17 Jan 2008 02:27:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H9RP9b080192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2008 02:27:26 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.138] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id m0H9RJSG008850; Thu, 17 Jan 2008 03:27:23 -0600 Message-ID: <478F2D0B.7060809@defuze.org> Date: Thu, 17 Jan 2008 10:25:15 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Peter Keane CC: James Abley , "'Atom-Syntax'" Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0H9RQ28080201 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Peter Keane a =E9crit : > A use-case, if it's of interest: We have an online digital library=20 > application, which contains images (jpg,png,gif,tiff), also PDFs,=20 > audio files (mp3,wav), video (mpeg4, etc). It's widely used here at UT=20 > Austin, mostly for instructional purposes, but also for=20 > content-managing media rich web sites [0]. It uses Atom extensively=20 > for moving data around and for archiving collections. > > I typically get EXIF data from jpegs, id3v2 medatadata from mp3s, and=20 > IPTC > data from images when possible. I can use the content element in Atom t= o > capture metadata about the primary media file, but it's that metadata=20 > that > varies per media file that I need to deal with (height, width, bitrate, > stereo/mono, aspect ratio, md5 hash, etc.) in atom:link. I typically use those existing meta-data as well and simply try to map=20 them to Dublin Core elements, which has proven to be quite hard=20 considering how generic DC can be. I do not try to extend the Atom=20 namespace usually but rather re-use an existing one (for instance for=20 multimedia resources I often try to use Mpeg7). I'm not sure however to understand what the atom:link could provide. If=20 it was to specify a given taxonomy, why not define it in terms of=20 atom:category/@term in a given scheme instead? - Sylvain From owner-atom-syntax@mail.imc.org Thu Jan 17 07:55:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFUHU-0007aw-U2 for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 07:55:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFUHT-0001jR-2K for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 07:55:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HCd9ce098329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 05:39:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HCd91g098328; Thu, 17 Jan 2008 05:39:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HCd8ll098321 for ; Thu, 17 Jan 2008 05:39:08 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=jsx+gHryAm7MyqUSPa56T/EI/fKkY5TL8mCSFmSTL+Cdy4wTRiW3z Sg4IWVzaWHM0rkQcMcEVk0PvfOf1cHmdhoYNUjFnScn1BQYlPBVuO qxAulQtQY4RtTc+jr0NYNL8+El/mn4y4AJ1Xw62XemwV0+1r8RMsA kRFc63I2e1JY=; Received: from wb6-a.mail.utexas.edu ([128.83.126.144]) by ironman.mail.utexas.edu with ESMTP; 17 Jan 2008 06:39:08 -0600 Received: (qmail 64894 invoked from network); 17 Jan 2008 12:39:07 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb6.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 17 Jan 2008 12:39:07 -0000 Date: Thu, 17 Jan 2008 06:39:07 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: Sylvain Hellegouarch cc: James Abley , "'Atom-Syntax'" Subject: Re: Atom feed design for a variety of media types In-Reply-To: <478F2D0B.7060809@defuze.org> Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> <478F2D0B.7060809@defuze.org> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Thu, 17 Jan 2008, Sylvain Hellegouarch wrote: > > I'm not sure however to understand what the atom:link could provide. If it > was to specify a given taxonomy, why not define it in terms of > atom:category/@term in a given scheme instead? > Actually, I was thinking of using atom:link to capture the bits of metadata that would vary per media file. Ex: ... mono 128 stereo 44.1 120 120 --peter > - Sylvain > From owner-atom-syntax@mail.imc.org Thu Jan 17 08:10:03 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFUVP-00077E-6R for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 08:10:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFUVO-0002H0-Et for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 08:10:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HCsaF8099413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 05:54:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HCsZ0a099412; Thu, 17 Jan 2008 05:54:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HCsS6X099401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2008 05:54:29 -0700 (MST) (envelope-from elunt@google.com) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id m0HCsNpO029111 for ; Thu, 17 Jan 2008 12:54:24 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject: in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RfBPYMz7lw9uAD37Ixk9QmHkKS92rBzwLtNRelztVJOJe2vpPzoogBPFK40OgzSqh NhjsHNXICQ57nLBNDo6jg== Received: from fk-out-0910.google.com (fkzz23.prod.google.com [10.94.52.23]) by zps76.corp.google.com with ESMTP id m0HCsLjr015903 for ; Thu, 17 Jan 2008 04:54:22 -0800 Received: by fk-out-0910.google.com with SMTP id z23so407178fkz.5 for ; Thu, 17 Jan 2008 04:54:21 -0800 (PST) Received: by 10.78.167.12 with SMTP id p12mr2513364hue.20.1200574461038; Thu, 17 Jan 2008 04:54:21 -0800 (PST) Received: by 10.78.152.3 with HTTP; Thu, 17 Jan 2008 04:54:20 -0800 (PST) Message-ID: Date: Thu, 17 Jan 2008 06:54:20 -0600 From: "Eric Lunt" To: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: <478E28EB.1070203@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_137_14053178.1200574461021" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> X-Google-Sender-Auth: 4c3cbbed49bd2fae Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 ------=_Part_137_14053178.1200574461021 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'd definitely be interested in this as well, and we could update FeedBurner's namespace translation to help ease the transition between old and new clients so that even if someone used the new namespace, for example= , we could still generate the appropriate iTunes tags when iTunes comes calling for the feed. I still think there's a lot of promise in the Media RSS namespace, but the lack of activity and support around it makes me a little hesitant to recommend it. - Eric On Jan 16, 2008 9:55 AM, James M Snell wrote: > > All it would really take are implementors willing to support the > extensions once they were defined and a group of individuals willing to > do the work to define them. I'm willing to help. > > - James > > Sylvain Hellegouarch wrote: > > > > Peter Keane a =E9crit : > >> > >> > >> > >> On Mon, 14 Jan 2008, James M Snell wrote: > >> > >>> I had been involved in some discussions a while back geared towards > >>> working on a standard set of media extensions derived from the itunes > >>> and yahoo media extensions. Unfortunately, that work never > >>> progressed. Such work would certainly not be unwelcome. > >>> > >>> - James > >> > >> Absolutely. It would be a huge boon for the sort of work we are > >> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. > >> A Media-rich Atom standard would be a no-brainer for that area (and > >> with FeedSync or a FeedSync-type standard along with it, a very > >> powerful platform indeed). > >> > >> Any thoughts on how such a process might be re-booted? > > > > I concur and I'd join such work if it existed. > > > > - Sylvain > > > > > > ------=_Part_137_14053178.1200574461021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'd definitely be interested in this as well, and we could update FeedB= urner's namespace translation to help ease the transition between old a= nd new clients so that even if someone used the new namespace, for example,= we could still generate the appropriate iTunes tags when iTunes comes call= ing for the feed. I still think there's a lot of promise in the Media R= SS namespace, but the lack of activity and support around it makes me a lit= tle hesitant to recommend it.

- Eric

On Jan 16, 2008 9:55 AM, J= ames M Snell <jasnell@gmail.com= > wrote:

All it would really take are implementors willing to support the
ext= ensions once they were defined and a group of individuals willing to
do = the work to define them.  I'm willing to help.

- James

Sylvain Hel= legouarch wrote:
>
> Peter Keane a =E9crit :
>>
>= ;>
>>
>> On Mon, 14 Jan 2008, James M Snell wrote:
>>
>>> I had been involved in some discussions a while ba= ck geared towards
>>> working on a standard set of media extens= ions derived from the itunes
>>> and yahoo media extensions. &n= bsp;Unfortunately, that work never
>>> progressed.  Such work would certainly not be unwelco= me.
>>>
>>> - James
>>
>> Absolut= ely.  It would be a huge boon for the sort of work we are
>> = trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage.
>> A Media-rich Atom standard would be a no-brainer for that area= (and
>> with FeedSync or a FeedSync-type standard along with it, = a very
>> powerful platform indeed).
>>
>> Any t= houghts on how such a process might be re-booted?
>
> I concur and I'd join such work if it existed.
>=
> - Sylvain
>
>

------=_Part_137_14053178.1200574461021-- From owner-atom-syntax@mail.imc.org Thu Jan 17 10:29:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWgG-0004cX-NK for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 10:29:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFWgE-0006W5-SR for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 10:29:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HFE3kC012276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 08:14:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HFE22J012275; Thu, 17 Jan 2008 08:14:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HFE1m3012269 for ; Thu, 17 Jan 2008 08:14:02 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=FsSCdim9imYoVhNpvSAI/wBmPpde8q9zhfM7EjBftMw7hrmm/4rOw iEDJj/tuqJ1XpqBXGwPw90rnRlvIwC+GYkXQndgGrG2CTCjTPxoyQ qYtblW9dhCcOKuQFnK+mqkxbZ+Cppg1mC751vqAD5qMJsQolmQncm MfdDlw7VxMWs=; Received: from wb6-a.mail.utexas.edu ([128.83.126.144]) by ironmaiden.mail.utexas.edu with ESMTP; 17 Jan 2008 09:14:01 -0600 Received: (qmail 44211 invoked from network); 17 Jan 2008 15:14:01 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb6.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 17 Jan 2008 15:14:01 -0000 Date: Thu, 17 Jan 2008 09:14:01 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: Eric Lunt cc: "'Atom-Syntax'" , karl@w3.org Subject: Re: Atom feed design for a variety of media types In-Reply-To: Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1439958570-1200582841=:14236" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1439958570-1200582841=:14236 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0HFE3kC012276 Does anyone here know the status of this effort by the w3c: Comparing Media RSS formats http://www.w3.org/2005/07/media-and-rss.html the page was last updated 7/27/2005 --peter keane On Thu, 17 Jan 2008, Eric Lunt wrote: > I'd definitely be interested in this as well, and we could update > FeedBurner's namespace translation to help ease the transition between = old > and new clients so that even if someone used the new namespace, for exa= mple, > we could still generate the appropriate iTunes tags when iTunes comes > calling for the feed. I still think there's a lot of promise in the Med= ia > RSS namespace, but the lack of activity and support around it makes me = a > little hesitant to recommend it. > > - Eric > > On Jan 16, 2008 9:55 AM, James M Snell wrote: > >> >> All it would really take are implementors willing to support the >> extensions once they were defined and a group of individuals willing t= o >> do the work to define them. I'm willing to help. >> >> - James >> >> Sylvain Hellegouarch wrote: >>> >>> Peter Keane a =E9crit : >>>> >>>> >>>> >>>> On Mon, 14 Jan 2008, James M Snell wrote: >>>> >>>>> I had been involved in some discussions a while back geared towards >>>>> working on a standard set of media extensions derived from the itun= es >>>>> and yahoo media extensions. Unfortunately, that work never >>>>> progressed. Such work would certainly not be unwelcome. >>>>> >>>>> - James >>>> >>>> Absolutely. It would be a huge boon for the sort of work we are >>>> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage. >>>> A Media-rich Atom standard would be a no-brainer for that area (and >>>> with FeedSync or a FeedSync-type standard along with it, a very >>>> powerful platform indeed). >>>> >>>> Any thoughts on how such a process might be re-booted? >>> >>> I concur and I'd join such work if it existed. >>> >>> - Sylvain >>> >>> >> >> > --0-1439958570-1200582841=:14236-- From owner-atom-syntax@mail.imc.org Thu Jan 17 11:28:53 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXbp-0007PQ-FS for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:28:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFXbn-0007hH-5X for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:28:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGEqCv017926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 09:14:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HGEq2V017925; Thu, 17 Jan 2008 09:14:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGEpTV017914 for ; Thu, 17 Jan 2008 09:14:52 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so158253anc.44 for ; Thu, 17 Jan 2008 08:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=NVe0JSerRiSo9+/o8rS3VGOZtYD039+ZNrdk7EgmOno=; b=n+nBunw+n3l2pLIjZ9Or8MDtHGR1OK4SuwBcX8sd4JFJCFNZX/PFGDFMEoKJRyVehNhWqogXm45fi6KO/o+kD2dX7A32A7A2E21rPepC6qTie0CmZcRV02+VYcbXfRDDNM644b1pJmtJXKyR14OAltF5iRvsXUe0Bj5nd9afTNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=IkoJReyoHwZNJ0AJeoKHHZONuqtapiigb3zIbJOvccRdWF6mvrh1Cdx/eABjxIEFjNonjFZCijhnZ7zli6aGsrcY/Wg6iOGKXwt7PGfaorW/KQNE3eRdhSmj4tSwZg4A89vdFrTSn6gpc4D5SFIm8rx0qbcfwtgcGf5he9aZJKE= Received: by 10.100.120.15 with SMTP id s15mr4714809anc.62.1200586490959; Thu, 17 Jan 2008 08:14:50 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id p27sm3736574ele.8.2008.01.17.08.14.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jan 2008 08:14:50 -0800 (PST) Message-ID: <478F7EF5.8080704@gmail.com> Date: Thu, 17 Jan 2008 08:14:45 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Sylvain Hellegouarch CC: Peter Keane , James Abley , "'Atom-Syntax'" Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> <478F2D0B.7060809@defuze.org> In-Reply-To: <478F2D0B.7060809@defuze.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0HGEqCv017926 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa It has actually been a while since I've looked at this area so I'm not=20 really up to date on the existing markup options beyond Media RSS and=20 the itunes extensions. It would be very helpful if someone could=20 provide a brief overview of existing media metadata options, including=20 where those options are being used. - James Sylvain Hellegouarch wrote: >=20 >=20 > Peter Keane a =E9crit : >> A use-case, if it's of interest: We have an online digital library=20 >> application, which contains images (jpg,png,gif,tiff), also PDFs,=20 >> audio files (mp3,wav), video (mpeg4, etc). It's widely used here at UT= =20 >> Austin, mostly for instructional purposes, but also for=20 >> content-managing media rich web sites [0]. It uses Atom extensively=20 >> for moving data around and for archiving collections. >> >> I typically get EXIF data from jpegs, id3v2 medatadata from mp3s, and=20 >> IPTC >> data from images when possible. I can use the content element in Atom = to >> capture metadata about the primary media file, but it's that metadata=20 >> that >> varies per media file that I need to deal with (height, width, bitrate= , >> stereo/mono, aspect ratio, md5 hash, etc.) in atom:link. >=20 > I typically use those existing meta-data as well and simply try to map=20 > them to Dublin Core elements, which has proven to be quite hard=20 > considering how generic DC can be. I do not try to extend the Atom=20 > namespace usually but rather re-use an existing one (for instance for=20 > multimedia resources I often try to use Mpeg7). >=20 > I'm not sure however to understand what the atom:link could provide. If= =20 > it was to specify a given taxonomy, why not define it in terms of=20 > atom:category/@term in a given scheme instead? >=20 > - Sylvain >=20 >=20 From owner-atom-syntax@mail.imc.org Thu Jan 17 11:29:21 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXcH-0008Ge-2V for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:29:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFXcG-0007ig-H9 for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:29:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGCGFK017651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 09:12:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HGCGb7017650; Thu, 17 Jan 2008 09:12:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGCF7B017642 for ; Thu, 17 Jan 2008 09:12:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0506.google.com with SMTP id n1so528347nzf.4 for ; Thu, 17 Jan 2008 08:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Yh4Exr9X6ZmWk8hWEXmzEn2KCAHNiSb3HVodkHI1rM8=; b=vkkqkE9UVJIIB2lN8+m/bTFF+Sp4aEh/vGOFEDdZcsKbXLXmXmmlaf0S1WroxuDqFzhFopkA0BwTznD8htLmftLAWpenA3v1sRM9Qy80OL5PZbZ7x9rabUGxWMgF9eTG1teXdSmpU69EnT6hp5xPEAvR5hZodTtv89NqNWjdl8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=gHZqR0yvsurIvqX/dMovrmPtA3PCDA2QvhmfjdQAijhd4OzfJi1kC0c31roSvUcmilDlQY1tu6/pfkU2UdRNkMK0Ezxi1fTi7U/uCasjJwHywh0z4katGrXDnAWYKaPvjXMS0c5vAK4PHj+flHvgTsJVblyq+e2g+Ecfknmdur4= Received: by 10.141.171.6 with SMTP id y6mr1583416rvo.84.1200586334217; Thu, 17 Jan 2008 08:12:14 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 2sm1092873rvi.32.2008.01.17.08.12.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jan 2008 08:12:12 -0800 (PST) Message-ID: <478F7E53.7000400@gmail.com> Date: Thu, 17 Jan 2008 08:12:03 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James Holderness CC: "'Atom-Syntax'" Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 +1 on every point. - James James Holderness wrote: > > Peter Keane wrote: >> It strikes me that any of: 1. saying that using >> Yahoo Media RSS is a "best practice", 2. "porting" Yahoo Media RSS to a >> more Atom-like syntax and implementing that, 3. doing something else >> entirely -- would be fine. > > It's hard to recommend the Yahoo module as a best practice when the spec > has been broken for years, and Yahoo is apparently incapable of fixing > it, despite having know of the problem for more than 6 months now (at > least). > > Also, it would nice if whatever you did still worked (albeit with less > functionality) with clients that weren't aware of your extensions. That > means using a basic Atom enclosure link as your starting point, and then > adding any extensions on top of that. > > Regards > James > > From owner-atom-syntax@mail.imc.org Thu Jan 17 11:38:41 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXlJ-0004WF-47 for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:38:41 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFXlI-0007uj-KP for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:38:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGLt1K018885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 09:21:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HGLt5K018884; Thu, 17 Jan 2008 09:21:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.247]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGLqiu018874 for ; Thu, 17 Jan 2008 09:21:55 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by hs-out-2122.google.com with SMTP id 55so548196hsc.10 for ; Thu, 17 Jan 2008 08:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=P14EIYfMv0x3bfxMlSnxH0QwpamS1OkXibHNWTYVKCU=; b=dTQZtTrylaABHlslrMBlnKFALvL9vsls7Orpd+L0VxZjVNg6Yr/HOGOfzdhGQWGiKUP4hQHNKVXrZLSa2lfwu0Qu6M8SzYfSEWM6O4PkQktNhUNNyyehEtO92+tqqxolojJlnmmO3eHAunAVXw3bZeGUsQXPQeWmcBaJlrCOhas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=AvGqDuJC/LUPm4Df1BvnRi5JnfJWolZEakD6zRZSf70whGupbucbopP/W3gx7XfFaIuR3U6Pm2uJb+S489WzOuGsHQGL+wsZqzFsJOX/WvBBV05q4cKE0ncBGo0uLvnZz7mVm0OjFlj1FHaJU4WI/PU5XrGIbkggTo9h0aPLJss= Received: by 10.100.7.1 with SMTP id 1mr4726232ang.73.1200586912182; Thu, 17 Jan 2008 08:21:52 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id q26sm3779425ele.6.2008.01.17.08.21.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jan 2008 08:21:50 -0800 (PST) Message-ID: <478F809B.7060004@gmail.com> Date: Thu, 17 Jan 2008 08:21:47 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eric Lunt CC: atom-syntax@imc.org Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0HGLt1K018885 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is definitely good to hear. - James Eric Lunt wrote: > I'd definitely be interested in this as well, and we could update=20 > FeedBurner's namespace translation to help ease the transition between=20 > old and new clients so that even if someone used the new namespace, for= =20 > example, we could still generate the appropriate iTunes tags when iTune= s=20 > comes calling for the feed. I still think there's a lot of promise in=20 > the Media RSS namespace, but the lack of activity and support around it= =20 > makes me a little hesitant to recommend it. >=20 > - Eric >=20 > On Jan 16, 2008 9:55 AM, James M Snell > wrote: >=20 >=20 > All it would really take are implementors willing to support the > extensions once they were defined and a group of individuals willin= g to > do the work to define them. I'm willing to help. >=20 > - James >=20 > Sylvain Hellegouarch wrote: > > > > Peter Keane a =E9crit : > >> > >> > >> > >> On Mon, 14 Jan 2008, James M Snell wrote: > >> > >>> I had been involved in some discussions a while back geared to= wards > >>> working on a standard set of media extensions derived from the > itunes > >>> and yahoo media extensions. Unfortunately, that work never > >>> progressed. Such work would certainly not be unwelcome. > >>> > >>> - James > >> > >> Absolutely. It would be a huge boon for the sort of work we ar= e > >> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the > rage. > >> A Media-rich Atom standard would be a no-brainer for that area = (and > >> with FeedSync or a FeedSync-type standard along with it, a very > >> powerful platform indeed). > >> > >> Any thoughts on how such a process might be re-booted? > > > > I concur and I'd join such work if it existed. > > > > - Sylvain > > > > >=20 >=20 From owner-atom-syntax@mail.imc.org Thu Jan 17 11:44:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFXqj-0001Ky-Bo for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:44:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFXqh-00086b-3F for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 11:44:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGKGCi018623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 09:20:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HGKGYn018622; Thu, 17 Jan 2008 09:20:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HGKFGm018612 for ; Thu, 17 Jan 2008 09:20:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so158739anc.44 for ; Thu, 17 Jan 2008 08:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=JWqk7iTwdj/Oan1e6CBpx2RPDx0Sejd52lPAlxIZ2iM=; b=pzvgbcUJXbd8m4fBacTcRt1lZv/VzAiRAUxTvG/mxXPG4I2Z7gMtpKbVnfnAGq4gRJQrnEms34f0RmxkqQXkS+KIs1Y4q+iLRg6SbVl/jqVxD+7yNr3sxZvPoUCfr5mCDWByAoxckbTeJCu+vCk9azyGbuxA5owXDrBJbm6cxtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=HxDh+EbVFhXTYvZ2PN6ldmd2CMDOlaza5QQ6De24cmx0JRU/YT4W4Ii4XMn01QxAu22H92yf+ZPPJ+0mqp9wmhIcAGj/BU1y23qCjZm0Hfj3ZWsxoeUycYjMJXpdFbQzGNzm1EpBK7LNzqxQtt5nm0my2dT6qTLo2v8waUwRsfo= Received: by 10.100.214.15 with SMTP id m15mr4757045ang.25.1200586815376; Thu, 17 Jan 2008 08:20:15 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id n26sm3762098ele.7.2008.01.17.08.20.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jan 2008 08:20:14 -0800 (PST) Message-ID: <478F8038.8080306@gmail.com> Date: Thu, 17 Jan 2008 08:20:08 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Peter Keane CC: Sylvain Hellegouarch , James Abley , "'Atom-Syntax'" Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <23fce8e60801161633q6c99b97cobe5bea8cbe4556a4@mail.gmail.com> <478F2D0B.7060809@defuze.org> In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 FWIW, quite some time ago I had proposed a set of "Atom link extensions" that, at the time, failed to get any momentum. Some details here: http://www.snellspace.com/wp/?p=247. One of the criticisms of that work was that while rfc4287 allowed the atom:link element to have child elements, it was not clear how many implementations would actually be able to do anything with them. Another issue was whether implementations that could get to the extensions actually would do anything with them. - James Peter Keane wrote: > > > > On Thu, 17 Jan 2008, Sylvain Hellegouarch wrote: >> >> I'm not sure however to understand what the atom:link could provide. >> If it was to specify a given taxonomy, why not define it in terms of >> atom:category/@term in a given scheme instead? >> > > Actually, I was thinking of using atom:link to capture the bits of > metadata that would vary per media file. Ex: > > > ... > > mono > 128 > > > > stereo > 44.1 > > > > 120 > 120 > > > > > --peter > > > >> - Sylvain >> > > From owner-atom-syntax@mail.imc.org Thu Jan 17 16:51:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFceO-0001Qc-32 for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 16:51:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFceN-0007JV-LX for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 16:51:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HLcNGM050467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 14:38:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0HLcNN0050466; Thu, 17 Jan 2008 14:38:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0HLcMhb050460 for ; Thu, 17 Jan 2008 14:38:23 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 14F804F11F; Thu, 17 Jan 2008 16:38:20 -0500 (EST) Cc: Eric Lunt , "'Atom-Syntax'" Message-Id: <3A4B025A-1A01-4091-B60F-3B557A3E3D97@w3.org> From: Karl Dubost To: Peter Keane In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Atom feed design for a variety of media types Date: Fri, 18 Jan 2008 06:38:20 +0900 References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> X-Mailer: Apple Mail (2.915) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0HLcNhb050461 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0HLcNGM050467 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Le 18 janv. 2008 =E0 00:14, Peter Keane a =E9crit : > Does anyone here know the status of this effort by the w3c: First of all :) first sentence in the page "This is an informal overview by the author(s), and not the product of a review by any formal W3C group." So it's not an effort by the W3C > Comparing Media RSS formats > http://www.w3.org/2005/07/media-and-rss.html > the page was last updated 7/27/2005 I did this page when there was discussions about media content in =20 atom, to see what was available at this time. If you have more up to =20 date information about it maybe I could add it to the page. Thanks. -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From owner-atom-syntax@mail.imc.org Thu Jan 17 22:40:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFi5m-0005js-5P for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 22:40:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFi5l-0004QN-Q3 for atompub-archive@lists.ietf.org; Thu, 17 Jan 2008 22:40:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I3Lf4g075813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 20:21:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I3LfKq075812; Thu, 17 Jan 2008 20:21:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m0I3Lc94075787 for ; Thu, 17 Jan 2008 20:21:40 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904645038 for ; Fri, 18 Jan 2008 14:21:07 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 18 Jan 2008 14:21:08 +1100 Subject: Re: Atom feed design for a variety of media types From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <478F8038.8080306@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On 18/1/08 3:20 AM, "James M Snell" wrote: > One of the criticisms of that work was that while rfc4287 allowed the > atom:link element to have child elements, it was not clear how many > implementations would actually be able to do anything with them. Another > issue was whether implementations that could get to the extensions > actually would do anything with them. that is pretty much par for the course for *any* extension though, right? e. From owner-atom-syntax@mail.imc.org Fri Jan 18 00:04:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjOl-0004cB-E3 for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 00:04:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFjOj-0005b3-TS for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 00:04:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I4q2XA081740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2008 21:52:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I4q25g081739; Thu, 17 Jan 2008 21:52:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I4q0Je081732 for ; Thu, 17 Jan 2008 21:52:01 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so220417anc.44 for ; Thu, 17 Jan 2008 20:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=R2yYOkfoOvFhuikwHf4YttHaFBubVJ3vMoMQ2ik4C3o=; b=uGE7970mrEY376VvmS/DTjOBKtv9o3Rrp5ePkP1c1RYWXv7mLaxq3riJKqze6HtWmlbfv5r3p3LzRB6Aqb/z7GxD5XUdFctReu+MMkAvbm3VLsuYDQc/j7/5PYhkrYQjDBXAyeUzUTvnpw9n9FqwWizcae4/7AU6e9IR45k0uD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=iYHxz/qX+o+Lmhi4vKN9Wol/xFqh1nQYLYne35WYMKIWAsT6clHAZ5NI2glHF9F2wE4Vjvm/n4YgUjZIiQ7wB5Wc3bF/NIEDFcQ8wcdAnVMMgeVDbKHif3W7s5u7It7G16FXokQZHT3S5Rd4MytzZ83Ia9N3VxDeCL9e0lkjhwc= Received: by 10.100.106.1 with SMTP id e1mr6180295anc.24.1200631920518; Thu, 17 Jan 2008 20:52:00 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id p27sm5061439ele.8.2008.01.17.20.51.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jan 2008 20:52:00 -0800 (PST) Message-ID: <4790306D.2020301@gmail.com> Date: Thu, 17 Jan 2008 20:51:57 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Atom feed design for a variety of media types References: In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Indeed, which is why I didn't think there was much merit in the argument back them either ;-) - James Eric Scheid wrote: > On 18/1/08 3:20 AM, "James M Snell" wrote: > >> One of the criticisms of that work was that while rfc4287 allowed the >> atom:link element to have child elements, it was not clear how many >> implementations would actually be able to do anything with them. Another >> issue was whether implementations that could get to the extensions >> actually would do anything with them. > > that is pretty much par for the course for *any* extension though, right? > > e. > > From owner-atom-syntax@mail.imc.org Fri Jan 18 02:39:47 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFlpL-0007UY-Eg for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 02:39:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFlpK-0000VI-UX for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 02:39:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I7SBj2094305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2008 00:28:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I7SBFW094304; Fri, 18 Jan 2008 00:28:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from randymail-a2.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I7SAL4094297 for ; Fri, 18 Jan 2008 00:28:10 -0700 (MST) (envelope-from lists@simplepie.org) Received: from [192.168.88.14] (71-94-42-86.static.trlk.ca.charter.com [71.94.42.86]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id D2F87EEE86; Thu, 17 Jan 2008 23:28:09 -0800 (PST) Message-Id: <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> From: Ryan Parman To: Atom-Syntax In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: Atom feed design for a variety of media types Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 17 Jan 2008 23:28:04 -0800 References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 If you take a look at this: > Comparing Media RSS formats > http://www.w3.org/2005/07/media-and-rss.html >> Even in this document, the wrong namespace is listed for Media RSS (the correct form -- and why the spec is broken -- should have a trailing slash). I'm doing some short-term contract work for Y!, completely unrelated to RSS/Atom. This very thread (as it pertains to Media RSS) was pointed out in an internal RSS mailing list today, with no response from the people who are supposed to be involved in this stuff. Either they're on vacation, or they've essentially checked-out from the Media RSS world. Heck, even Y! News uses the wrong namespace URL (and they even added an element or two that doesn't exist in the spec). Either way, it might be time for a responsible community member to fork version 1.1.2 of the spec, clean up the document, put together some unit tests for implementors, and add some sort of formal process around it so that the world can move on without Y!'s help (or lack thereof). ========================================= Ryan Parman Creator and Co-Developer SimplePie http://simplepie.org From owner-atom-syntax@mail.imc.org Fri Jan 18 03:39:29 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFml7-0001nL-CN for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 03:39:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFml5-0001gY-SQ for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 03:39:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I8RhJZ000408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2008 01:27:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I8Rhnl000407; Fri, 18 Jan 2008 01:27:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s12.bay0.hotmail.com (bay0-omc3-s12.bay0.hotmail.com [65.54.246.212]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I8ReCc000401 for ; Fri, 18 Jan 2008 01:27:43 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.23]) by bay0-omc3-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jan 2008 00:27:40 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jan 2008 00:27:40 -0800 Message-ID: Received: from 85.211.253.214 by BAY141-DAV13.phx.gbl with DAV; Fri, 18 Jan 2008 08:27:37 +0000 X-Originating-IP: [85.211.253.214] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> Subject: Re: Atom feed design for a variety of media types Date: Fri, 18 Jan 2008 08:27:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 18 Jan 2008 08:27:40.0422 (UTC) FILETIME=[FD500A60:01C859AB] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Ryan Parman wrote: > If you take a look at this: >> Comparing Media RSS formats >> http://www.w3.org/2005/07/media-and-rss.html > > Even in this document, the wrong namespace is listed for Media RSS (the > correct form -- and why the spec is broken -- should have a trailing > slash). The itunes namespace is wrong too (they had their own little namespace screwup for a while). It's all very funny until you have to try and do productive work with this rubbish. Regards James From owner-atom-syntax@mail.imc.org Fri Jan 18 04:06:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFnB3-0002e8-Bw for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 04:06:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFnB2-0002AW-Sq for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 04:06:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I8qGjS002129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2008 01:52:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I8qGTr002128; Fri, 18 Jan 2008 01:52:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s40.bay0.hotmail.com (bay0-omc3-s40.bay0.hotmail.com [65.54.246.240]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I8qFDY002122 for ; Fri, 18 Jan 2008 01:52:16 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.16]) by bay0-omc3-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jan 2008 00:52:15 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jan 2008 00:52:15 -0800 Message-ID: Received: from 85.211.253.214 by BAY141-DAV6.phx.gbl with DAV; Fri, 18 Jan 2008 08:52:14 +0000 X-Originating-IP: [85.211.253.214] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: Subject: Re: Atom feed design for a variety of media types Date: Fri, 18 Jan 2008 08:52:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 18 Jan 2008 08:52:15.0649 (UTC) FILETIME=[6C9DD110:01C859AF] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Eric Scheid wrote: > On 18/1/08 3:20 AM, "James M Snell" wrote: >> One of the criticisms of that work was that while rfc4287 allowed the >> atom:link element to have child elements, it was not clear how many >> implementations would actually be able to do anything with them. Another >> issue was whether implementations that could get to the extensions >> actually would do anything with them. > > that is pretty much par for the course for *any* extension though, right? Sure, but if you can't find anyone that intends to use your extension (and you need both clients and servers), you have to ask yourself why you're bothering to design it in the first place. Not that I'm saying that's the case for media extensions. I just don't think you should underestimate the importance of the question: will anyone use this? Regards James From owner-atom-syntax@mail.imc.org Fri Jan 18 05:03:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFo4l-00056t-Ly for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 05:03:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFo4j-0003ma-Ap for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 05:03:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I9pnfl006480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2008 02:51:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I9pno7006479; Fri, 18 Jan 2008 02:51:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I9pmF8006472 for ; Fri, 18 Jan 2008 02:51:49 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id ACE414EEDB; Fri, 18 Jan 2008 04:51:47 -0500 (EST) Cc: Atom-Syntax Message-Id: <9E6D56D3-44B8-457C-890D-4E1CC545EF17@w3.org> From: Karl Dubost To: Ryan Parman In-Reply-To: <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Atom feed design for a variety of media types Date: Fri, 18 Jan 2008 18:51:46 +0900 References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> X-Mailer: Apple Mail (2.915) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0I9pnF8006474 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0I9pnfl006480 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Le 18 janv. 2008 =E0 16:28, Ryan Parman a =E9crit : > If you take a look at this: >> Comparing Media RSS formats >> http://www.w3.org/2005/07/media-and-rss.html >>> > > Even in this document, the wrong namespace is listed for Media RSS =20 > (the correct form -- and why the spec is broken -- should have a =20 > trailing slash). I will be happy to modify it if someone gives me the good values :) =20 and point out other mistakes. Thanks -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From owner-atom-syntax@mail.imc.org Fri Jan 18 05:11:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoCF-0005Oo-9k for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 05:11:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFoCD-0003tR-QA for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 05:11:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I9wFx3006828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2008 02:58:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0I9wFDb006827; Fri, 18 Jan 2008 02:58:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0I9wEOr006821 for ; Fri, 18 Jan 2008 02:58:14 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 75C054EEDB; Fri, 18 Jan 2008 04:58:13 -0500 (EST) Cc: Atom-Syntax Message-Id: <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> From: Karl Dubost To: Ryan Parman In-Reply-To: <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Atom feed design for a variety of media types Date: Fri, 18 Jan 2008 18:58:12 +0900 References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> X-Mailer: Apple Mail (2.915) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0I9wEOr006822 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0I9wFx3006828 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Le 18 janv. 2008 =E0 16:28, Ryan Parman a =E9crit : > Even in this document, the wrong namespace is listed for Media RSS =20 > (the correct form -- and why the spec is broken -- should have a =20 > trailing slash). As the spec right now describe them * Apple - Last Change: no date :/ http://www.apple.com/itunes/store/podcaststechspecs.html#rss * Yahoo - Last Change: 2005-10-22 ? http://search.yahoo.com/mrss -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From miles-Huang@pmike.de Fri Jan 18 11:32:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFu8a-0007eu-0s for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 11:32:12 -0500 Received: from [190.199.161.142] (helo=[190.199.161.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFu8Y-0000V3-Qc for atompub-archive@lists.ietf.org; Fri, 18 Jan 2008 11:32:11 -0500 Received: by 10.89.156.183 with SMTP id zAszMQHzBkfCB; Fri, 18 Jan 2008 11:59:11 -0400 (GMT) Received: by 192.168.218.214 with SMTP id oIzCfAqeSrgoPd.9703065883278; Fri, 18 Jan 2008 11:59:09 -0400 (GMT) Message-ID: <785A2789.1AE2B8D8@pmike.de> Date: Fri, 18 Jan 2008 11:59:06 -0400 From: "miles Huang" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: erswoher Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Push it in harder cried Jenny when I showed her my new long schlong http://pneuso.com/
From nijiushovii@stcolmans.com Mon Jan 21 23:30:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHAme-0008Jo-77 for atompub-archive@lists.ietf.org; Mon, 21 Jan 2008 23:30:48 -0500 Received: from [98.18.20.99] (helo=[98.18.20.99]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHAmd-0004h8-NL for atompub-archive@lists.ietf.org; Mon, 21 Jan 2008 23:30:48 -0500 Received: from connecti-a33f84 ([118.154.32.87]:16887 "EHLO connecti-a33f84" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [98.18.41.180] with ESMTP id S22FVXGQOSURZGJY (ORCPT ); Mon, 21 Jan 2008 23:31:02 -0500 Message-ID: Date: Mon, 21 Jan 2008 23:30:50 -0500 From: User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: nigirits Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 It felt like heaven when Paul entered me, he was so much bigger now http://zhgeiaoa.com/
From owner-atom-syntax@mail.imc.org Tue Jan 22 01:53:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHD0g-0001I0-Rh for atompub-archive@lists.ietf.org; Tue, 22 Jan 2008 01:53:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHD0e-0000wt-5E for atompub-archive@lists.ietf.org; Tue, 22 Jan 2008 01:53:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0M6YYvT008429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2008 23:34:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0M6YYvJ008428; Mon, 21 Jan 2008 23:34:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0M6YXrQ008421 for ; Mon, 21 Jan 2008 23:34:33 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=KQqrouK6XGHVfPgWK88DVrUM/L2BKF4F41ejJ/bQDCl21XSn/Mbr7 CO7eWtFiLCl2m7cRdZli7aYeeDeNzmBSOgRjvqyc/j1KLo4u864co JqVXTPE+zQ5v8v0CeQeiWySxwZeAlxVI7fKzbr/T5IA2U8Yb018Lx /oYCaue4yjfo=; Received: from wb1-a.mail.utexas.edu ([128.83.126.134]) by ironmaiden.mail.utexas.edu with ESMTP; 22 Jan 2008 00:34:32 -0600 Received: (qmail 17894 invoked from network); 22 Jan 2008 06:34:32 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb1.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 22 Jan 2008 06:34:32 -0000 Date: Tue, 22 Jan 2008 00:34:32 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James Holderness cc: Atom Syntax Subject: Re: Atom feed design for a variety of media types In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 In taking a look back over the archives, I see that a good bit or discussion around links & link extension has already place [0], which I found enlightening (and I am happy to back away from rehashing old arguments if that all this ends up being). In the interest of putting the "what" before the "how", the goals here, as I understand it, would be to figure out a way to: 1. provide a way to add metadata to a particular atom:link 2. provide a way to group a set of links and/or to establish a relationship between links that appear in a single atom:entry and possibly to "type" those relationships and the means at our disposal: 1. the "rel" attribute of atom:link 2. new extension attributes of atom:link 3. child elements of atom link (and attributes on those elements). By sticking to those goals & means, I suspect you cover most use cases (at least ones that have at hand and/or am aware of), AND clients that DON'T implement such an extension shouldn't be hampered. The one bit of "how" I'd like to see (and this, I realize, may not be a majority opinion) would be to have every media entity have it's own atom:link, and not be made a child of another atom:link or made part of an enumerated, space-delimited list in an atom:link attribute. I.e., I would hope that the relationships/groups could be expressed as metadata "about" a link. (The challenge, of course, is to figure out a way to say "this is related to that" without identifying the "that" in the statement). James Snell's Atom Link Extension ID used a "group" attribute on atom:link with a case-insensitive opaque text string identifying the group. One would them need to rely on the type or rel attributes to discover the media entities "role" in that group. Not bad, I think. Grouping/relationships is the trickiest bit. Not as difficult, would be to come up with the list of metadata attributes that might be used with a link and figure out if they should be attributes on atom:link or children. If children (my preference), you could keep them fairly abstract and allow for an "open" set of possible values, e.g.: 391ea33cbe3a052e6b247c7b943d1a73 OR even: 128 stereo --Peter Keane [0] http://www.imc.org/atom-syntax/mail-archive/msg17378.html On Fri, 18 Jan 2008, James Holderness wrote: > > Eric Scheid wrote: >> On 18/1/08 3:20 AM, "James M Snell" wrote: >>> One of the criticisms of that work was that while rfc4287 allowed the >>> atom:link element to have child elements, it was not clear how many >>> implementations would actually be able to do anything with them. Another >>> issue was whether implementations that could get to the extensions >>> actually would do anything with them. >> >> that is pretty much par for the course for *any* extension though, right? > > Sure, but if you can't find anyone that intends to use your extension (and > you need both clients and servers), you have to ask yourself why you're > bothering to design it in the first place. > > Not that I'm saying that's the case for media extensions. I just don't think > you should underestimate the importance of the question: will anyone use > this? > > Regards > James > From ahcsegnaadet@artmarsho.de Wed Jan 23 04:01:11 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHbTr-0007Zu-Dw for atompub-archive@lists.ietf.org; Wed, 23 Jan 2008 04:01:11 -0500 Received: from [88.140.54.117] (helo=[84.6.111.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHbTl-0006MY-Pi for atompub-archive@lists.ietf.org; Wed, 23 Jan 2008 04:01:09 -0500 Received: from nom-w8kz05n5f7s ([154.183.182.137]:1430 "EHLO nom-w8kz05n5f7s" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [84.6.111.185] with ESMTP id S22DFJMVILJVEGUM (ORCPT ); Wed, 23 Jan 2008 10:01:37 +0100 Message-ID: <05E4D3D8.56AC6E53@artmarsho.de> Date: Wed, 23 Jan 2008 10:01:18 +0100 From: User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: aidopodu Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 In 3 months, have a brand new you and a huge monster in your pants http://mgeaioaw.com/
From paradox0980@northernlearning.co.uk Wed Jan 23 12:27:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHjNf-00050I-E3 for atompub-archive@lists.ietf.org; Wed, 23 Jan 2008 12:27:19 -0500 Received: from eos74.neoplus.adsl.tpnet.pl ([83.20.34.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHjNe-00080z-Nd for atompub-archive@lists.ietf.org; Wed, 23 Jan 2008 12:27:19 -0500 Received: (qmail 15902 invoked from network); Wed, 23 Jan 2008 18:27:23 +0100 Received: from unknown (HELO northernlearning.co.uk) (29.155.218.155) by mytrophycatch.com with SMTP; Wed, 23 Jan 2008 18:27:22 +0100 Received: from localhost.localdomain (n-gage.letstalk.com [86.219.140.251]) by northernlearning.co.uk (8.13.1/8.13.1) with SMTP id WaosuGsQ016055 for ; Wed, 23 Jan 2008 18:27:21 +0100 Message-Id: <907252284520.WaosuGsQ016055@067636.n-gage.letstalk.com> Received: from phpmailer ([127.0.0.1]) by n-gage.letstalk.com with HTTP; Wed, 23 Jan 2008 18:27:21 +0100 Date: Wed, 23 Jan 2008 18:27:21 +0100 To: atompub-archive@lists.ietf.org From: "paradox0" Subject: pannnung X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: paradox0980@northernlearning.co.uk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 1.5 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://newstruts4you.com/ Dignity, Pride and Good Taste, Your one stop shop for the Season's Top Designer Shoes From owner-atom-syntax@mail.imc.org Wed Jan 23 16:28:13 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHn8n-0006gq-8b for atompub-archive@lists.ietf.org; Wed, 23 Jan 2008 16:28:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHn8m-0007gY-Jw for atompub-archive@lists.ietf.org; Wed, 23 Jan 2008 16:28:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0NLDbRq028471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 14:13:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0NLDb7q028470; Wed, 23 Jan 2008 14:13:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s21.bay0.hotmail.com (bay0-omc3-s21.bay0.hotmail.com [65.54.246.221]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0NLDaJE028462 for ; Wed, 23 Jan 2008 14:13:36 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.22]) by bay0-omc3-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jan 2008 13:13:35 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 23 Jan 2008 13:13:35 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV12.phx.gbl with DAV; Wed, 23 Jan 2008 21:13:34 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> Subject: Re: Atom feed design for a variety of media types Date: Wed, 23 Jan 2008 21:15:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 23 Jan 2008 21:13:35.0910 (UTC) FILETIME=[D0FBC460:01C85E04] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Karl Dubost wrote: > * Apple - Last Change: no date :/ > http://www.apple.com/itunes/store/podcaststechspecs.html#rss > version="2.0"> I believe that is correct. > * Yahoo - Last Change: 2005-10-22 ? > http://search.yahoo.com/mrss > That is what the current spec says, but that's not correct. There's an official acknowledgement of the mistake here: http://tech.groups.yahoo.com/group/rss-media/message/1008 Regards James From iaretimivbxwl@HOLZMANLAW.COM Fri Jan 25 13:56:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JITj0-00034T-O8 for atompub-archive@lists.ietf.org; Fri, 25 Jan 2008 13:56:26 -0500 Received: from host67-133-dynamic.30-79-r.retail.telecomitalia.it ([79.30.133.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JITj0-0001rR-3v for atompub-archive@lists.ietf.org; Fri, 25 Jan 2008 13:56:26 -0500 Received: (qmail 49991 invoked from network); Fri, 25 Jan 2008 19:56:25 +0100 Received: from unknown (HELO HOLZMANLAW.COM) (212.164.40.46) by with SMTP; Fri, 25 Jan 2008 19:56:24 +0100 Received: from localhost.localdomain ( [100.199.88.239]) by HOLZMANLAW.COM (8.13.1/8.13.1) with SMTP id JUnBZSqX377925 for ; Fri, 25 Jan 2008 19:56:23 +0100 Message-Id: <449286412036.JUnBZSqX377925@328596.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Fri, 25 Jan 2008 19:56:23 +0100 Date: Fri, 25 Jan 2008 19:56:23 +0100 To: atompub-archive@lists.ietf.org From: "iaretimi" Subject: hsuyuuyk X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: iaretimivbxwl@HOLZMANLAW.COM MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://www.tostrutlive.com/ Save today 60% Off ALL Designer Footwear such as Gucci Prada Chanel From owner-atom-syntax@mail.imc.org Sat Jan 26 05:02:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIhrV-0001vu-C3 for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 05:02:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIhrU-000786-Sc for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 05:02:09 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0Q9mIBm012335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2008 02:48:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0Q9mI9J012334; Sat, 26 Jan 2008 02:48:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from randymail-a11.g.dreamhost.com (balanced.mail.policyd.dreamhost.com [208.97.132.119]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0Q9mHba012327 for ; Sat, 26 Jan 2008 02:48:18 -0700 (MST) (envelope-from lists@simplepie.org) Received: from [192.168.0.20] (c-67-182-118-73.hsd1.ca.comcast.net [67.182.118.73]) by randymail-a11.g.dreamhost.com (Postfix) with ESMTP id 32D40109EB5; Sat, 26 Jan 2008 01:48:17 -0800 (PST) From: Ryan Parman To: James Holderness In-Reply-To: Subject: Re: Atom feed design for a variety of media types X-Priority: 3 References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sat, 26 Jan 2008 01:48:16 -0800 Cc: "Atom-Syntax" X-Mailer: Apple Mail (2.915) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Correct. David Hall is no longer with Yahoo, and charge over the spec has fallen to Jeremy Zadowny. Unfortunately, Jeremy has pretty much ignored all requests to fix the spec, so we've got past and present versions of the spec with different namespaces. Yay. ========================================= Ryan Parman Creator and Co-Developer SimplePie http://simplepie.org On Jan 23, 2008, at 1:15 PM, James Holderness wrote: > > Karl Dubost wrote: >> * Apple - Last Change: no date :/ >> http://www.apple.com/itunes/store/podcaststechspecs.html#rss >> > version="2.0"> > > I believe that is correct. > >> * Yahoo - Last Change: 2005-10-22 ? >> http://search.yahoo.com/mrss >> > > That is what the current spec says, but that's not correct. There's > an official acknowledgement of the mistake here: > > http://tech.groups.yahoo.com/group/rss-media/message/1008 > > Regards > James > From 1wolrabcepyi@ECOPAC.COM.AU Sat Jan 26 13:56:48 2008 Return-path: <1wolrabcepyi@ECOPAC.COM.AU> Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIqCu-00058R-BR for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 13:56:48 -0500 Received: from [151.60.226.131] (helo=[151.60.226.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIqCp-0006iu-L2 for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 13:56:44 -0500 Received: (qmail 38037 invoked from network); Sat, 26 Jan 2008 19:56:32 +0100 Received: from unknown (HELO ECOPAC.COM.AU) (36.133.23.65) by with SMTP; Sat, 26 Jan 2008 19:56:31 +0100 Received: from localhost.localdomain ( [9.111.47.54]) by ECOPAC.COM.AU (8.13.1/8.13.1) with SMTP id HottyVFY934897 for ; Sat, 26 Jan 2008 19:56:30 +0100 Message-Id: <615012879983.HottyVFY934897@846554.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Sat, 26 Jan 2008 19:56:30 +0100 Date: Sat, 26 Jan 2008 19:56:30 +0100 To: atompub-archive@lists.ietf.org From: "1wolrab" <1wolrabcepyi@ECOPAC.COM.AU> Subject: 1signet X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: 1wolrabcepyi@ECOPAC.COM.AU MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://tostrutshop.com/ Gucci Prada Dsquared D&G & Other Top Fashion Designer Shoes and Boots Amazing DEALS HERE From owner-atom-syntax@mail.imc.org Sat Jan 26 14:41:03 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIqtj-0000XP-8O for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 14:41:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIqtg-0005wV-Qf for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 14:41:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0QJO4R0062540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2008 12:24:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0QJO4vY062539; Sat, 26 Jan 2008 12:24:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0QJO3EU062533 for ; Sat, 26 Jan 2008 12:24:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so250540anc.44 for ; Sat, 26 Jan 2008 11:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=bz0NTB50sNJDf7/RX1X/x7LsCycgzNA498WiU2t4Oeg=; b=nq0az56weP2EAj2LUzvVgm4zqPF4OqX/7vDdQ+vdiGABDvoZg58B0VNPtRvSII+ATDl2zhRoMwl+/xCb904WFL8oKMGAD5VQFFwLwk7B4F9JXvFDx6M/lBMDcl4ELVgBBBpfDE6EntFhiX8xSnPaU6+Om6gueZKcLKVNtWSWPYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=QjUYTWevBeZVRxEQLV4F3LheQ/v1zFq6qEEsRdIy7qU8NLSjdUj6pffW4TM5pUoZXJ7Y+uEjEksvACU+P1op5xX6+SJRXlUB77Srt5BwXgzwTCr6J+CYYt5f67YNItIm28NJmrD8viGmJrHdYE7pI1c5w3qV51LenCxZcWWXIE8= Received: by 10.100.91.17 with SMTP id o17mr7529087anb.6.1201375443503; Sat, 26 Jan 2008 11:24:03 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id h2sm6060862rnb.17.2008.01.26.11.24.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jan 2008 11:24:02 -0800 (PST) Message-ID: <479B88CF.3070000@gmail.com> Date: Sat, 26 Jan 2008 11:23:59 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Ryan Parman CC: James Holderness , Atom-Syntax Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Ok, not a good situation. Like I said before, all it really takes to get something started here is enough interest from a community of folks willing to do the work and implement support. Assuming we have that, we need to start documenting some requirements. Grouping: The ability to group alternative representations of the same content. For instance, video may be encoded as wmv, mov, mpg, etc. We need the ability to specify a single default representation Generic content metadata: Every piece of content has general metadata applicable to all alternate representations. These include title, description, rating, keywords, categorization, copyright, license, credits, captioning, lyrics, distribution restrictions, etc. Media specific metadata: Each media resource has metadata specific to the media type. We need the ability to express the appropriate metadata for each resource. This metadata may vary across alternative representations of the same content. These include things like the url, file size, type, medium, bit rate, frame rate, sampling rate, channels, duration, display dimensions, language, hash, software, Previews: The ability to specify a content preview such as a thumbnail, a shortened video snippet, a transcript, etc. Previews may be offered in multiple formats. If there's anything missing from this, please respond and help fill in the gaps. Once we have the requirements documented, we might as well start knocking around a straw man... ... tag:example.org,2008:/shows My Dog's Wedding 2008-12-12T12:12:12Z 2008-12-12T12:12:12Z 2007-12-13T12:12:12Z James My dog got married the other day Copyright (c) 2008 James Linda Joe The Dog <i>...</i> <i>...</i> ... ... ... ... ... ... ... ... ... ... ... ... ... ... Is this better or worse than the yahoo/itunes approaches? Why? Does it make more sense to use a more iterative approach building from either the yahoo or itunes schemas? What are the other possible approaches? - James Ryan Parman wrote: > > Correct. David Hall is no longer with Yahoo, and charge over the spec > has fallen to Jeremy Zadowny. Unfortunately, Jeremy has pretty much > ignored all requests to fix the spec, so we've got past and present > versions of the spec with different namespaces. > > Yay. > > > ========================================= > Ryan Parman > Creator and Co-Developer > SimplePie > > http://simplepie.org > > > > On Jan 23, 2008, at 1:15 PM, James Holderness wrote: > >> >> Karl Dubost wrote: >>> * Apple - Last Change: no date :/ >>> http://www.apple.com/itunes/store/podcaststechspecs.html#rss >>> >> version="2.0"> >> >> I believe that is correct. >> >>> * Yahoo - Last Change: 2005-10-22 ? >>> http://search.yahoo.com/mrss >>> >> >> That is what the current spec says, but that's not correct. There's an >> official acknowledgement of the mistake here: >> >> http://tech.groups.yahoo.com/group/rss-media/message/1008 >> >> Regards >> James >> > > From owner-atom-syntax@mail.imc.org Sat Jan 26 15:49:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIrxd-0003SY-RC for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 15:49:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIrxc-0007Jz-7f for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 15:49:09 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0QKXlIA068235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2008 13:33:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0QKXlLr068234; Sat, 26 Jan 2008 13:33:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s25.bay0.hotmail.com (bay0-omc1-s25.bay0.hotmail.com [65.54.246.97]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0QKXkDg068224 for ; Sat, 26 Jan 2008 13:33:47 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.11]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jan 2008 12:33:45 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 26 Jan 2008 12:33:45 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV1.phx.gbl with DAV; Sat, 26 Jan 2008 20:33:45 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> Subject: Re: Atom feed design for a variety of media types Date: Sat, 26 Jan 2008 20:35:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 26 Jan 2008 20:33:45.0508 (UTC) FILETIME=[BF6E9E40:01C8605A] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 James M Snell wrote: > Ok, not a good situation. Like I said before, all it really takes to get > something started here is enough interest from a community of folks > willing to do the work and implement support. For the record, I'm not interested in supporting anything like this at the moment. My only interest is in making sure that whatever you do doesn't render the feed useless to people that don't support the extension. > term="au us" /> > term="ca fr" /> I'm not sure these are a good fit for the category element. All the other examples make sense as category elements without the client knowing anything about the scheme. > > Linda > Any reason why these can't be atom:contributor elements, possibly with an x:role attribute or sub-element? Would be more useful to clients not supporting the extension and I don't think it would be an inappropriate use of atom:contributor. > That doesn't look legal to me. Surely the IRI reference in the src attribute must be dereferenceable? Section 4.1.3.2 of RFC4287: "Atom Processors MAY use the IRI to retrieve the content". How does one retrieve content from a fragment reference? > Is this better or worse than the yahoo/itunes approaches? Why? Looks better so far. Less reinvention of core elements. > What are the other possible approaches? As a client developer, I'd want to ask what metadata might be useful to clients first and foremost. Come up with some use cases that amount to more than just "have metadata - must publish". Regards James From owner-atom-syntax@mail.imc.org Sat Jan 26 17:27:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JItUj-0003jj-Em for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 17:27:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JItUi-0001nJ-TD for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 17:27:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0QMDt2S078102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2008 15:13:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0QMDtQ5078101; Sat, 26 Jan 2008 15:13:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0QMDrfg078093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Jan 2008 15:13:54 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.138] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id m0QMDeaQ017871; Sat, 26 Jan 2008 16:13:46 -0600 Message-ID: <479BBE7E.1020001@defuze.org> Date: Sat, 26 Jan 2008 23:13:02 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James Holderness CC: Atom-Syntax Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > > As a client developer, I'd want to ask what metadata might be useful > to clients first and foremost. Come up with some use cases that amount > to more than just "have metadata - must publish". It seems to me that it's one of those potential edge cases where we may end up arguing ad libitum without reaching an agreement because not everyone uses the Atom format with the same expectation. Atom may have come from the blogging world but it's pretty clear that it gradually becomes the de facto envelop format for any kind of exchange. Personally I'm not sure whether or not this thread is about "extending the atom vocabulary with common metadata about media resources in order to enrich Atom" or "defining developers' best practices for inlining metadata with their own namespace in an Atom document". The former point is quite interesting to me since we could capitalize on Atom being seen as a clean and versatile standard and propel the next media metadata storage and exchange format with it.The latter point seems simply a case of using atom:content with an appropriate media-type. However if we decide to extend the atom vocabulary like Yahoo did with Media-RSS, we ought to actually discuss first with the main players in the field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the minimal relevant set of metadata for common media formats. In some way maybe should we expand on the discussion taking place at the microformats wiki [1]. - Sylvain [1] http://microformats.org/wiki/media-metadata-examples From owner-atom-syntax@mail.imc.org Sat Jan 26 22:12:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIxwC-0005k8-Jh for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 22:12:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIxwC-0000v8-2F for atompub-archive@lists.ietf.org; Sat, 26 Jan 2008 22:12:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R2xK0F097156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2008 19:59:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0R2xKuV097155; Sat, 26 Jan 2008 19:59:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R2xJY3097145 for ; Sat, 26 Jan 2008 19:59:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so273579anc.44 for ; Sat, 26 Jan 2008 18:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=iO1Ok0TOT/lF2uuPseMylcLcn+S6up/fT5+0bJGHafY=; b=CtZRptihNhviIF8mVbilOXPLZOcyHW2KxmjoTjYFsLqx/4kmkZZb1BNauBnYhaQm4DwrItIWAPrOIDIuQQZbuK/V/S4BDd3YegJ7Dv5chzmXHRp6aCkMp7xS0Dhb+PL18RS3sQjLpI5NH+Eq64fByEncYYw2cabz4cI/pzsfA+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=w6XSpPM4T1yL7FTVEeEu9CtgECTgYQM63qOOgkUwj7KP0KE026mZDH8eFRdU325bMKsfRloJVU3PyqHHqthAezhz8xg1WN/MmIkSZ/W3XQewR0VQkQ7R7FidxIB0BfE4PGZ8x+pyyxkSP5mPTlwHk3OyS4E49U3UCEo/FUb5dsI= Received: by 10.100.247.14 with SMTP id u14mr8245125anh.85.1201402758915; Sat, 26 Jan 2008 18:59:18 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id h2sm6579682rnb.17.2008.01.26.18.59.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jan 2008 18:59:17 -0800 (PST) Message-ID: <479BF382.8050101@gmail.com> Date: Sat, 26 Jan 2008 18:59:14 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: James Holderness CC: Atom-Syntax Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 James Holderness wrote: > > James M Snell wrote: >> Ok, not a good situation. Like I said before, all it really takes to >> get something started here is enough interest from a community of >> folks willing to do the work and implement support. > > For the record, I'm not interested in supporting anything like this at > the moment. My only interest is in making sure that whatever you do > doesn't render the feed useless to people that don't support the extension. > I'm not convinced that there are very many implementers at all who are going to be interested. >> > term="au us" /> >> > term="ca fr" /> > > I'm not sure these are a good fit for the category element. All the > other examples make sense as category elements without the client > knowing anything about the scheme. > +1. it felt odd when I typed it also; but this is a strawman and needs to be kicked around a bit. Are these really going to be necessary, anyway? >> >> Linda >> > > Any reason why these can't be atom:contributor elements, possibly with > an x:role attribute or sub-element? Would be more useful to clients not > supporting the extension and I don't think it would be an inappropriate > use of atom:contributor. > Right. I was thinking the same thing. >> > > That doesn't look legal to me. Surely the IRI reference in the src > attribute must be dereferenceable? Section 4.1.3.2 of RFC4287: "Atom > Processors MAY use the IRI to retrieve the content". How does one > retrieve content from a fragment reference? > It is dereferencable... just not in the way most implementations would likely expect. :-) Anyway, the main point is that given a set of links with a given rel (e.g. "enclosure") how do we identify which is the "primary" or "default" representation? >> Is this better or worse than the yahoo/itunes approaches? Why? > > Looks better so far. Less reinvention of core elements. > Yeah, that was the main goal. >> What are the other possible approaches? > > As a client developer, I'd want to ask what metadata might be useful to > clients first and foremost. Come up with some use cases that amount to > more than just "have metadata - must publish". > Heh... ok. As a client developer, what metadata might be useful to you? :-) - James > Regards > James > > From owner-atom-syntax@mail.imc.org Sun Jan 27 03:18:45 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ2iz-0005pK-CU for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 03:18:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ2ix-0008Gj-Rq for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 03:18:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R88om8012715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 01:08:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0R88o2Z012714; Sun, 27 Jan 2008 01:08:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m0R88l7R012695 for ; Sun, 27 Jan 2008 01:08:49 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904806102 for ; Sun, 27 Jan 2008 18:19:29 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 27 Jan 2008 18:19:39 +1100 Subject: Re: Atom feed design for a variety of media 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 27/1/08 7:35 AM, "James Holderness" wrote: >> >> Linda >> > > Any reason why these can't be atom:contributor elements, possibly with an > x:role attribute or sub-element? Would be more useful to clients not > supporting the extension and I don't think it would be an inappropriate use > of atom:contributor. hmm .. in drafting RFC 4287 did we disallow the following construct: Linda (sidenote: if this is illegal in Atom 1.0 (RFC 4287), would this be something that would require a new version to introduce (eg. Atom 1.1) with corresponding tweaking of the xmlns:atom?) e. From owner-atom-syntax@mail.imc.org Sun Jan 27 03:19:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ2ji-0006J8-8L for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 03:19:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ2jh-0008HI-RC for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 03:19:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R88mjQ012707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 01:08:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0R88mhK012706; Sun, 27 Jan 2008 01:08:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m0R88l7P012695 for ; Sun, 27 Jan 2008 01:08:47 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904806096 for ; Sun, 27 Jan 2008 18:12:29 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 27 Jan 2008 18:12:38 +1100 Subject: Re: Atom feed design for a variety of media 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On 27/1/08 7:35 AM, "James Holderness" wrote: >> > term="au us" /> >> > term="ca fr" /> > > I'm not sure these are a good fit for the category element. All the other > examples make sense as category elements without the client knowing anything > about the scheme. also, are you (James) implying a space delimited semantic in the @terms? is this: the same as: e. From owner-atom-syntax@mail.imc.org Sun Jan 27 03:49:41 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ3Cv-0006yN-9W for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 03:49:41 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ3Cu-0000JV-SH for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 03:49:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R8dgPI014656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 01:39:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0R8dgkJ014655; Sun, 27 Jan 2008 01:39:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R8dfej014647 for ; Sun, 27 Jan 2008 01:39:42 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so285459anc.44 for ; Sun, 27 Jan 2008 00:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=2l99jFI0wsRIRKYEFV3NjqNCnjtiP+6Wa1RO75FEZPU=; b=v2lDCEaE9XollGJAVWmvRKnaKUE48NrfDRlSkJbIpw2qTHkEnaj1uLu9jk3GZYnQn4wDEN5NgWmwBUhqcVQ3GonCeGb504qi/0HUry2VUF9XZW9Xovird9YQsdQ1MxZ93zJ+VG2x5lai4fP+ngm9CWK0q5zCfzXhqpbJ2zKdj7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=abl6EuMLkBNKnY+8flFRC7recrCOAN9h95MRmhVli/A9MKrr+uq5DHBMiTGieFp2mu0AhgqUNuyFaEcyI6FcZrV+OoSw3fsH5IqvnJsczgXCD/MK8PhywR9oQ8ur9/+uucB1dVgaDLAADfPFwdr+e/paI23BRqOXV0rSwv6dILU= Received: by 10.100.135.16 with SMTP id i16mr8870909and.33.1201423181646; Sun, 27 Jan 2008 00:39:41 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id i52sm7067900rne.2.2008.01.27.00.39.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Jan 2008 00:39:41 -0800 (PST) Message-ID: <479C434A.8080808@gmail.com> Date: Sun, 27 Jan 2008 00:39:38 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Atom feed design for a variety of media types References: In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I'm not implying or suggesting anything. It's just a strawman intended to help stimulate discussion about what The Right Way To Do It should be. - James Eric Scheid wrote: > On 27/1/08 7:35 AM, "James Holderness" wrote: > >>> >> term="au us" /> >>> >> term="ca fr" /> >> I'm not sure these are a good fit for the category element. All the other >> examples make sense as category elements without the client knowing anything >> about the scheme. > > also, are you (James) implying a space delimited semantic in the @terms? > > is this: > scheme="http://example.org/restriction/country/allow" > term="au us" > /> > > the same as: > scheme="http://example.org/restriction/country/allow" > term="us au" > /> > > e. > > From owner-atom-syntax@mail.imc.org Sun Jan 27 05:06:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ4Pf-0000kq-Bm for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 05:06:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ4Pe-0006mx-Ps for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 05:06:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R9t7el018619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 02:55:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0R9t7Cs018618; Sun, 27 Jan 2008 02:55:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s17.bay0.hotmail.com (bay0-omc1-s17.bay0.hotmail.com [65.54.246.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0R9t6Wu018610 for ; Sun, 27 Jan 2008 02:55:07 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.19]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jan 2008 01:55:05 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Jan 2008 01:55:05 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV9.phx.gbl with DAV; Sun, 27 Jan 2008 09:55:04 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BF382.8050101@gmail.com> Subject: Re: Atom feed design for a variety of media types Date: Sun, 27 Jan 2008 09:57:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 27 Jan 2008 09:55:05.0887 (UTC) FILETIME=[B1923AF0:01C860CA] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 James M Snell wrote: >>> >> term="au us" /> >>> >> term="ca fr" /> > > +1. it felt odd when I typed it also; but this is a strawman and needs to > be kicked around a bit. Are these really going to be necessary, anyway? Well either those values are informative (don't bother trying to download this link if you're in France since it's not going to work); or they're meant to be a cheap form of DRM (you MUST NOT download this link if you're from France or the RIAA will try and have you arrested). In the former case the values can't be trusted (and the client probably won't know where it is anyway), so it's easiest to just download the link anyway and see what works. The latter case is unenforceable so it's pointless. So unless I'm missing something, I don't see the need. > It is dereferencable... just not in the way most implementations would > likely expect. :-) RFC3986: "When a same-document reference is dereferenced for a retrieval action [...] a dereference should not result in a new retrieval action." So what exactly does one do with such a link? How do you get back a quick-time video from that feed without performing a new retrieval action? I may be missing something but I don't think that's defined. If it's going to break existing implementations that aren't doing anything wrong, then I think you should avoid it. > Anyway, the main point is that given a set of links with a given rel (e.g. > "enclosure") how do we identify which is the "primary" or "default" > representation? I understand the intention - I just think you need to come up with another way of doing that. > Heh... ok. As a client developer, what metadata might be useful to you? > :-) None actually. But I don't do anything fancy with enclosures. All I really need is a well-written title attribute, so if I display a list of enclosures to the user, they can make an informed decision about which ones they might want to download. If I *was* doing something fancy with enclosures (like some kind of download manager), there are probably a number of things I might find useful, but stuff like sampling rate and color depth would not be on that list. Now I'm sure there are other use-cases that might benefit from other metadata, but you really need to find people that actually intend to do something with this stuff before you try and lock down what it will be. So far the only concrete use-case I've heard here was for some form of proprietary data exchange, and frankly you might as well use a proprietary extension for that (actually I don't even see the point of using Atom for that). Regards James From rialzo469@aerialsports.org Sun Jan 27 06:00:49 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ5Fp-0008L0-SN for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 06:00:49 -0500 Received: from host90-80-dynamic.16-79-r.retail.telecomitalia.it ([79.16.80.90] helo=host28-84-dynamic.20-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJ5Fp-00052n-8V for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 06:00:49 -0500 Received: (qmail 33074 invoked from network); Sun, 27 Jan 2008 12:00:50 +0100 Received: from unknown (HELO aerialsports.org) (19.132.39.198) by with SMTP; Sun, 27 Jan 2008 12:00:49 +0100 Received: from localhost.localdomain ( [107.35.175.139]) by aerialsports.org (8.13.1/8.13.1) with SMTP id FyFlHebL968867 for ; Sun, 27 Jan 2008 12:00:48 +0100 Message-Id: <122935902538.FyFlHebL968867@369027.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Sun, 27 Jan 2008 12:00:48 +0100 Date: Sun, 27 Jan 2008 12:00:48 +0100 To: atompub-archive@lists.ietf.org From: "rialzo" Subject: rhipsali X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: rialzo469@aerialsports.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://ogjeioagt.com/ Make a difference to her life, increase her pleasure, increase your length and thickness within weeks From owner-atom-syntax@mail.imc.org Sun Jan 27 06:01:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ5G8-00006h-Cy for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 06:01:08 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ5G7-0007sl-VY for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 06:01:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0RAo794022018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 03:50:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0RAo7vI022017; Sun, 27 Jan 2008 03:50:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s11.bay0.hotmail.com (bay0-omc3-s11.bay0.hotmail.com [65.54.246.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0RAo6FS022011 for ; Sun, 27 Jan 2008 03:50:07 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.19]) by bay0-omc3-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jan 2008 02:50:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Jan 2008 02:50:06 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV9.phx.gbl with DAV; Sun, 27 Jan 2008 10:50:04 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> Subject: Re: Atom feed design for a variety of media types Date: Sun, 27 Jan 2008 10:52:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 27 Jan 2008 10:50:06.0454 (UTC) FILETIME=[60DCC960:01C860D2] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Sylvain Hellegouarch wrote: > Atom may have come from the blogging world but it's pretty clear that it > gradually becomes the de facto envelop format for any kind of exchange. The question is why? I don't see much benefit in using Atom over some proprietary form of XML (but plenty of disadvantages) unless you specifically intend the data to be readable in a typical, blog-reading, Atom client as well. I suspect there's a lot of cargo-cult engineering behind many uses of Atom outside the blogging world. Just because you can wrap your data in an Atom envelope, that doesn't mean you should. > However if we decide to extend the atom vocabulary like Yahoo did with > Media-RSS, we ought to actually discuss first with the main players in the > field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the > minimal relevant set of metadata for common media formats. We're back to the use-case of "have metadata - must publish". Why? Who wants that metadata? What for? Regards James From owner-atom-syntax@mail.imc.org Sun Jan 27 13:21:56 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJC8i-0005me-1P for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 13:21:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJC8g-0001Un-DW for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 13:21:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0RIBcnE056781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 11:11:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0RIBcxs056780; Sun, 27 Jan 2008 11:11:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironman.mail.utexas.edu (ironman.mail.utexas.edu [128.83.32.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0RIBbvj056769 for ; Sun, 27 Jan 2008 11:11:37 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=gGxRceI+WXMmSLCNGopiTQBMY8opJ2Sr68Lywrd/z1lUMKcl3eTA4 9pmZVDb4pjjzF3qUBG6CREnnjD4YUjgqxz3g1lqbEOh66EWXyzSnD Su7BM+4OYF5FLpYdeQwrcjTtshvO28YEGOGpPpQ+kLR43APVzJift nvldWlo2ib7k=; Received: from wb6-a.mail.utexas.edu ([128.83.126.144]) by ironman.mail.utexas.edu with ESMTP; 27 Jan 2008 12:11:37 -0600 Received: (qmail 3442 invoked from network); 27 Jan 2008 18:11:37 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb6.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 27 Jan 2008 18:11:37 -0000 Date: Sun, 27 Jan 2008 12:11:36 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James Holderness cc: Atom-Syntax Subject: Re: Atom feed design for a variety of media types In-Reply-To: Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 > -sereniditous re-use opportunities (e.g. "let's make a podcast of this > search...") s/sereniditous/serendipitous/ -pk From owner-atom-syntax@mail.imc.org Sun Jan 27 13:23:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJCAd-00072t-TW for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 13:23:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJCAc-0001YS-B6 for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 13:23:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0RI7gfc056433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 11:07:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0RI7gsJ056432; Sun, 27 Jan 2008 11:07:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0RI7fBP056423 for ; Sun, 27 Jan 2008 11:07:42 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=yQIsonn5iyztjPEt9blm6bb7/vsBxqpbqRMuD3aqDiR1ZAOR5mzOF PJE3aonroR43GfrJgp1xTB0zZ88GvS+7h9mf6tJKBRoxJO8eqBlpi y1NjHcnx5SlQKHNcxb0r1xhtbYfJ8Wq/go3F3WpozkukX25cdMAng gfBF0b++SDDI=; Received: from wb9-a.mail.utexas.edu ([128.83.126.150]) by ironmaiden.mail.utexas.edu with ESMTP; 27 Jan 2008 12:07:41 -0600 Received: (qmail 11968 invoked from network); 27 Jan 2008 18:07:41 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb9.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 27 Jan 2008 18:07:41 -0000 Date: Sun, 27 Jan 2008 12:07:41 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James Holderness cc: Atom-Syntax Subject: Re: Atom feed design for a variety of media types In-Reply-To: Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On Sun, 27 Jan 2008, James Holderness wrote: > > Sylvain Hellegouarch wrote: >> Atom may have come from the blogging world but it's pretty clear that it >> gradually becomes the de facto envelop format for any kind of exchange. > > The question is why? I don't see much benefit in using Atom over some > proprietary form of XML (but plenty of disadvantages) unless you specifically > intend the data to be readable in a typical, blog-reading, Atom client as > well. > Having built a heavily-used (here at UT Austin) CMS/DAM with Atom as the standard internal XML format, I have found all kinds of benefits (many of which I could've predicted, some I couldn't): -tool/library support -feed validator that allows me to sanity-check all sorts of internal operations -"introspecting" internal application processes w/ nothing more than Firefox -ability to "subscribe" to internal processes (including highly configurable search results) with a news reader/live bookmarks, etc. -sereniditous re-use opportunities (e.g. "let's make a podcast of this search...") -lightweight integration with MANY other systems of which all I need to ask is: "parse and Atom feed" to enumerate just a few. Thus, this talk of a better/enhanced mechanism for media description is of great interest, and I have high hopes that some consensus s=can be reached. --peter keane > I suspect there's a lot of cargo-cult engineering behind many uses of Atom > outside the blogging world. Just because you can wrap your data in an Atom > envelope, that doesn't mean you should. > >> However if we decide to extend the atom vocabulary like Yahoo did with >> Media-RSS, we ought to actually discuss first with the main players in the >> field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the >> minimal relevant set of metadata for common media formats. > > We're back to the use-case of "have metadata - must publish". Why? Who wants > that metadata? What for? > > Regards > James > From owner-atom-syntax@mail.imc.org Sun Jan 27 19:58:29 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJIKT-0002Cc-50 for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 19:58:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJIKR-0001m3-Ho for atompub-archive@lists.ietf.org; Sun, 27 Jan 2008 19:58:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0S0l0Xr089518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jan 2008 17:47:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0S0l0mg089517; Sun, 27 Jan 2008 17:47:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0S0kxL1089509 for ; Sun, 27 Jan 2008 17:47:00 -0700 (MST) (envelope-from karl@w3.org) Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 652204F303; Sun, 27 Jan 2008 19:46:58 -0500 (EST) Cc: James Holderness , Atom-Syntax Message-Id: From: Karl Dubost To: Sylvain Hellegouarch In-Reply-To: <479BBE7E.1020001@defuze.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Atom feed design for a variety of media types Date: Mon, 28 Jan 2008 09:46:57 +0900 References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> X-Mailer: Apple Mail (2.915) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0S0l0L1089512 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0S0l0Xr089518 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Le 27 janv. 2008 =E0 08:13, Sylvain Hellegouarch a =E9crit : > However if we decide to extend the atom vocabulary like Yahoo did =20 > with Media-RSS, we ought to actually discuss first with the main =20 > players in the field today (Apple, Microsoft, Xiph, EXIF, etc.) in =20 > order to define the minimal relevant set of metadata for common =20 > media formats. Just for information, there has been work done also by a [W3C =20 incubator][1] group on [Multimedia Vocabularies][2]. It gives an =20 overview of the existing formats and their associated metadata. It's =20 quite cool. # 1. Introduction * 1.1 Declaration of Namespaces * 1.2 Related Pages # 2. Types of Multimedia Metadata # 3. Existing Multimedia Metadata Formats * 3.1 Multimedia Metadata Formats For Describing Still Images * 3.2 Multimedia Metadata Formats For Describing Audio Content * 3.3 Multimedia Metadata Formats For Describing Audio-Visual =20 Content * 3.4 Multimedia Metadata Formats For Describing Multimedia =20 Presentations * 3.5 Multimedia Metadata Formats For Describing Specific Domains =20 Or Workflows * 3.6 Other Multimedia Metadata Related Formats [1]: http://www.w3.org/2005/Incubator/ [2]: http://www.w3.org/2005/Incubator/mmsem/XGR-vocabularies/ -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From owner-atom-syntax@mail.imc.org Mon Jan 28 06:45:31 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSQd-0000uR-0r for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 06:45:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJSQc-0005lE-Hm for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 06:45:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SBR7QB039117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 04:27:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SBR7k1039116; Mon, 28 Jan 2008 04:27:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc1-s12.bay0.hotmail.com (bay0-omc1-s12.bay0.hotmail.com [65.54.246.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SBR6TI039108 for ; Mon, 28 Jan 2008 04:27:06 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.15]) by bay0-omc1-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jan 2008 03:27:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 28 Jan 2008 03:27:05 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV5.phx.gbl with DAV; Mon, 28 Jan 2008 11:27:02 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> Subject: Re: Atom feed design for a variety of media types Date: Mon, 28 Jan 2008 11:29:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 28 Jan 2008 11:27:05.0826 (UTC) FILETIME=[B61FD420:01C861A0] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Peter Keane wrote: > On Sun, 27 Jan 2008, James Holderness wrote: >> The question is why? I don't see much benefit in using Atom over some >> proprietary form of XML (but plenty of disadvantages) unless you >> specifically intend the data to be readable in a typical, blog-reading, >> Atom client as well. > > Having built a heavily-used (here at UT Austin) CMS/DAM with Atom as the > standard internal XML format, I have found all kinds of benefits (many of > which I could've predicted, some I couldn't): > > -tool/library support > -feed validator that allows me to sanity-check all sorts of internal > operations > -"introspecting" internal application processes w/ nothing more than > Firefox It seems to me you'd get the same kind of benefits from plain old XML. > -ability to "subscribe" to internal processes (including highly > configurable search results) with a news reader/live bookmarks, etc. > -sereniditous re-use opportunities (e.g. "let's make a podcast of this > search...") Knowing what you know now, would you list these as reasons for choosing Atom in a future project along the same line? If so, you're designing a system that you specifically intend to be readable in a typical, blog-reading, Atom client - and I've already said that may be a good reason to choose Atom. The fact that you may not have predicted these benefits in your last project is no reason to choose Atom blindly for future projects, hoping that you might just get some other unpredicted benefits. Atom isn't magic. It worked well on your current system for specific reasons. That doesn't necessarily make it a good envelope format for any kind of exchange. If you're going to use it, know why you're using it. Regards James From owner-atom-syntax@mail.imc.org Mon Jan 28 11:47:39 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJX90-0006IK-Tg for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 11:47:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJX8z-00048v-2J for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 11:47:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SGVDoZ069793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 09:31:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SGVDQd069792; Mon, 28 Jan 2008 09:31:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SGVCj6069784 for ; Mon, 28 Jan 2008 09:31:13 -0700 (MST) (envelope-from pkeane@mail.utexas.edu) DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns; h=Received:Received:Received:Date:From:X-X-Sender:To:cc: Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=EWT6lj+AxZEUeSOruFqm6kg2hjJlF+Shdfoy6pcxO2ncUil/95hvL /ZtTS1EDsJb1BBFq2qXwIfD3N9A4SeFBI1WAk5RIB1aCI78lngeTM X3sFkW8MnfryGisYWDu9Yb/nBYt0RGcguFFuDJ3hl15rIvwAOIr6T wmPJA3StWeh0=; Received: from wb8-a.mail.utexas.edu ([128.83.126.148]) by ironmaiden.mail.utexas.edu with ESMTP; 28 Jan 2008 10:31:12 -0600 Received: (qmail 19256 invoked from network); 28 Jan 2008 16:31:11 -0000 Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7) by wb8.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 28 Jan 2008 16:31:11 -0000 Date: Mon, 28 Jan 2008 10:31:11 -0600 (CST) From: Peter Keane X-X-Sender: pkeane@harpo.laits.utexas.edu To: James Holderness cc: Atom-Syntax Subject: Re: Atom feed design for a variety of media types In-Reply-To: Message-ID: References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> User-Agent: Alpine 1.00 (BSO 882 2007-12-20) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 On Mon, 28 Jan 2008, James Holderness wrote: > > Peter Keane wrote: >> Having built a heavily-used (here at UT Austin) CMS/DAM with Atom as the >> standard internal XML format, I have found all kinds of benefits (many of >> which I could've predicted, some I couldn't): >> >> -tool/library support >> -feed validator that allows me to sanity-check all sorts of internal >> operations >> -"introspecting" internal application processes w/ nothing more than >> Firefox > > It seems to me you'd get the same kind of benefits from plain old XML. > Yes, but will the 101 folks that choose to use the "feeds" made available in my app by way of lightweight REST-based web services? How about when my design choices propagate to all kinds of applications (many of the quick & dirty variety) that I will never even be aware of. >> -ability to "subscribe" to internal processes (including highly >> configurable search results) with a news reader/live bookmarks, etc. >> -sereniditous re-use opportunities (e.g. "let's make a podcast of this >> search...") > > Knowing what you know now, would you list these as reasons for choosing Atom > in a future project along the same line? If so, you're designing a system > that you specifically intend to be readable in a typical, blog-reading, Atom > client - and I've already said that may be a good reason to choose Atom. > The system is designed to use the richer metadata that I include within the atom:content element and encoded as simple xhtml definition lists. Just so happens it looks real nice in a feed reader. But my app will be doing more with that information. And thanks to GRDDL & RDF/a should provide opportunites for MORE benefits (note that the "cost" here -- using xhtml -- was zero. Just following good design principles). > The fact that you may not have predicted these benefits in your last project > is no reason to choose Atom blindly for future projects, hoping that you > might just get some other unpredicted benefits. Atom isn't magic. > Perhaps, but it may be surprising to some how well the Atom model maps to current use scenarios all over the place. Maybe higher ed is unique in that way, but folks sure seem do have a lot of stuff that fits. Qouting Tim Bray in "Don't Invent XML Languages" [0]: "Suppose you think of your data as a list of, well, anything: stock prices or workflow steps or cake ingredients or sports statistics. Atom might be for you. Suppose the things in the list ought to have human-readable labels and have to carry a timestamp and might be re-aggregated into other lists. Atom is almost certainly what you need. And for a data format that didn't exist a year ago, there's a whole great big butt-load of software that understands it." > It worked well on your current system for specific reasons. That doesn't > necessarily make it a good envelope format for any kind of exchange. If > you're going to use it, know why you're using it. > As Roy F. says: "Engineer for serendipity" [1] Note that I don't come to this conclusion w/o a bit of hand-wringing.[2] --peter keane > Regards > James > [0] http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages [1] http://tech.groups.yahoo.com/group/rest-discuss/message/8343 [2] http://blogs.law.harvard.edu/pkeane/2007/10/29/more-on-why-use-atomatompub/ From owner-atom-syntax@mail.imc.org Mon Jan 28 16:25:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbTr-0007iG-7X for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 16:25:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJbTo-0006C8-JU for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 16:25:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SLBpxm094400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 14:11:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SLBpmI094399; Mon, 28 Jan 2008 14:11:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SLBlb8094388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jan 2008 14:11:49 -0700 (MST) (envelope-from kmarvin@google.com) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id m0SLBhGc015260 for ; Mon, 28 Jan 2008 21:11:45 GMT DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:references; b=cUNjPgGZ85jZTnp67h3344ML1ZhuDs/JviIXxVnCpBcRUX9H0+D0zSJkxSo9n/Z7+ TlUemJMpY0bMiwJCwESaQ== Received: from wr-out-0506.google.com (wrac55.prod.google.com [10.54.54.55]) by zps76.corp.google.com with ESMTP id m0SLAvgv001521 for ; Mon, 28 Jan 2008 13:11:43 -0800 Received: by wr-out-0506.google.com with SMTP id c55so939753wra.0 for ; Mon, 28 Jan 2008 13:11:42 -0800 (PST) Received: by 10.142.97.20 with SMTP id u20mr2724036wfb.203.1201554702602; Mon, 28 Jan 2008 13:11:42 -0800 (PST) Received: by 10.142.89.20 with HTTP; Mon, 28 Jan 2008 13:11:42 -0800 (PST) Message-ID: <192fc9640801281311o103f750exf8e990861e166e4d@mail.gmail.com> Date: Mon, 28 Jan 2008 15:11:42 -0600 From: "Kyle Marvin" To: "James Holderness" Subject: Re: Atom feed design for a variety of media types Cc: Atom-Syntax In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12287_1634782.1201554702606" References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 ------=_Part_12287_1634782.1201554702606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jan 27, 2008 4:52 AM, James Holderness wrote: > > Sylvain Hellegouarch wrote: > > Atom may have come from the blogging world but it's pretty clear that it > > gradually becomes the de facto envelop format for any kind of exchange. > > The question is why? I don't see much benefit in using Atom over some > proprietary form of XML (but plenty of disadvantages) unless you > specifically intend the data to be readable in a typical, blog-reading, > Atom > client as well. Hi James, Here's my view from the trenches... There are significant benefits to having normalized metadata with well-understood semantics across a wide variety of types of data. At Google, we've been using Atom + AtomPub as the foundation of the Google Data APIs for almost two years now; the first such API (for Google Calendar) launched in April 2006 and Atom+AtomPub is now the baseline API model for Blogger, several media-oriented services (ex Picasa and YouTube) as well as for a variety of other Google services (Google Calendar, Google Base, Google Apps Provisioning, ...). A few examples of where normalized metadata is of benefit: - having a guid (atom:id) that lets you uniquely identify a resource and easily correlate it with the same resource received indirectly through different routes or at different points in time. - having a timestamp (atom:updated) that lets you identify the last time a resource changed and possibly tell if the version you have locally is up-to-date with a remotely managed version of the same resource. - the ability to get a list (atom:feed) of such resources to perform correlation and up-to-date checks w/out requiring a large number of HTTP operations (i.e. GETs on individual resources) - a set of conventions for both where and how to interact with the resource (atom:link), such as how to modify or delete it (rel="edit"), how to find an html-viewable version (rel="alternate"), how to add new resources to a resource set, etc. - a model for how to discover and use resource sets (Atom introspection) You get all of the above benefits no matter what the actual "data type" associated with the resource is, i.e. whether it's a blog entry, a photo, a video, a calendar event, a provisioned user, ... It's also worth noting that while all the above metadata was created to enable syndication-oriented use cases, the applicability of much of the metadata goes beyond that specific use case. > I suspect there's a lot of cargo-cult engineering behind many uses of Atom > outside the blogging world. Just because you can wrap your data in an Atom > envelope, that doesn't mean you should. > I think looking at this only from the perspective of Atom syntax vs a custom XML grammar is perhaps too narrow of a view. Certainly, there may be aspects of the syntax that are less of a good fit for certain types of data and also some additional conventions that need to be developed (as discussed on this list). On the whole, the benefits you get from using a metadata syntax with well-defined and standardized semantics (Atom) and also an associated well-defined and standardized HTTP-based interaction model (AtomPub) significantly outweighs the drawbacks, as least that has been our experience over the year and a half of exposing data for a variety of different Google services using Atom and AtomPub. Prior to centering on Atom+AtomPub, I'd probably characterize our API strategy for different services as fairly ad hoc and diverse; Given this, I don't believe we'd ever have been able to launch the quantity of services we have in the last year and half if we hadn't chosen a common approach that created leverage and the ability to roll them out while only requiring incremental API design and domain-specific customization based upon the type of resource(s) being exposed. More importantly, picking a common approach (both in syntax and interaction style) means that external client developers can leverage common tools (many now in open source form, like Abdera) and knowledge across multiple Atom/AtomPub-based Google services that would never have been possible before if we'd chosen a more ad hoc API strategy for each individual service. With the specs now done and more high-quality open source implementations of Atom/AtomPub becoming available, I'm optimistic that others will leverage the same benefits that we've seen with GData (both for exposing resource-oriented services and for consuming them). > > > However if we decide to extend the atom vocabulary like Yahoo did with > > Media-RSS, we ought to actually discuss first with the main players in > the > > field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the > > minimal relevant set of metadata for common media formats. > > We're back to the use-case of "have metadata - must publish". Why? Who > wants > that metadata? What for? > These questions might possibly be a red herring. The interesting question is who wants the *data* and what are the use cases for it. We see a wide variety of answers to that question for our APIs: desktop apps, browser-based apps, mobile apps, syndication, publishers, aggregators, ... The real question w/ respect to metadata is whether there are benefits to having standardized conventions for metadata across data types and associated web-friendly conventions for how you interact with both the metadata and the data. Most importantly, do such conventions contribute positively to the wide variety of use cases for the data in ways that go beyond blogging and syndication? My take on the answer to that: Absolutely! Cheers! -- Kyle > Regards > James > > ------=_Part_12287_1634782.1201554702606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jan 27, 2008 4:52 AM, James Holderness <j4_james@hotmail.com> wrote:

Sylvain Hellegouarch wrote:
> Atom may have come from the blogging world but it's pretty clear that it
> gradually becomes the de facto envelop format for any kind of exchange.

The question is why? I don't see much benefit in using Atom over some
proprietary form of XML (but plenty of disadvantages) unless you
specifically intend the data to be readable in a typical, blog-reading, Atom
client as well.

Hi James,

Here's my view from the trenches...

There are significant benefits to having normalized metadata with well-understood semantics across a wide variety of types of data.   At Google, we've been using Atom + AtomPub as the foundation of the Google Data APIs for almost two years now; the first such API (for Google Calendar) launched in April 2006 and Atom+AtomPub is now the baseline API model for Blogger, several media-oriented services (ex Picasa and YouTube) as well as for a variety of other Google services (Google Calendar, Google Base, Google Apps Provisioning, ...).

A few examples of where normalized metadata is of benefit:

- having a guid (atom:id) that lets you uniquely identify a resource and easily correlate it with the same resource received indirectly through different routes or at different points in time.

- having a timestamp (atom:updated) that lets you identify the last time a resource changed and possibly tell if the version you have locally is up-to-date with a remotely managed version of the same resource.

- the ability to get a list (atom:feed) of such resources to perform correlation and up-to-date checks w/out requiring a large number of HTTP operations (i.e. GETs on individual resources)

- a set of conventions for both where and how to interact with the resource (atom:link), such as how to modify or delete it (rel="edit"), how to find an html-viewable version (rel="alternate"), how to add new resources to a resource set, etc.

- a model for how to discover and use resource sets (Atom introspection)

You get all of the above benefits no matter what the actual "data type" associated with the resource is, i.e. whether it's a blog entry, a photo, a video, a calendar event, a provisioned user, ...    It's also worth noting that while all the above metadata was created to enable syndication-oriented use cases, the applicability of much of the metadata goes beyond that specific use case.


I suspect there's a lot of cargo-cult engineering behind many uses of Atom
outside the blogging world. Just because you can wrap your data in an Atom
envelope, that doesn't mean you should.

I think looking at this only from the perspective of Atom syntax vs a custom XML grammar is perhaps too narrow of a view.  Certainly, there may be aspects of the syntax that are less of a good fit for certain types of data and also some additional conventions that need to be developed (as discussed on this list).   On the whole, the benefits you get from using a metadata syntax with well-defined and standardized semantics (Atom) and also an associated well-defined and standardized HTTP-based interaction model (AtomPub) significantly outweighs the drawbacks, as least that has been our experience over the year and a half of exposing data for a variety of different Google services using Atom and AtomPub.

Prior to centering on Atom+AtomPub, I'd probably characterize our API strategy for different services as fairly ad hoc and diverse;  Given this, I don't believe we'd ever have been able to launch the quantity of services we have in the last year and half if we hadn't chosen a common approach that created leverage and the ability to roll them out while only requiring incremental API design and domain-specific customization based upon the type of resource(s) being exposed.   

More importantly, picking a common approach (both in syntax and interaction style) means that external client developers can leverage common tools (many now in open source form, like Abdera) and knowledge across multiple Atom/AtomPub-based Google services that would never have been possible before if we'd chosen a more ad hoc API strategy for each individual service.   

With the specs now done and more high-quality open source implementations of Atom/AtomPub becoming available, I'm optimistic that others will leverage the same benefits that we've seen with GData (both for exposing resource-oriented services and for consuming them).
 

> However if we decide to extend the atom vocabulary like Yahoo did with
> Media-RSS, we ought to actually discuss first with the main players in the
> field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the
> minimal relevant set of metadata for common media formats.

We're back to the use-case of "have metadata - must publish". Why? Who wants
that metadata? What for?

These questions might possibly be a red herring.  The interesting question is who wants the *data* and what are the use cases for it.  We see a wide variety of answers to that question for our APIs: desktop apps, browser-based apps, mobile apps,  syndication, publishers, aggregators, ...   

The real question w/ respect to metadata is whether there are benefits to having standardized conventions for metadata across data types and associated web-friendly conventions for how you interact with both the metadata and the data.  Most importantly, do such conventions contribute positively to the wide variety of use cases for the data in ways that go beyond blogging and syndication?  My take on the answer to that: Absolutely!

Cheers!

-- Kyle


Regards
James


------=_Part_12287_1634782.1201554702606-- From owner-atom-syntax@mail.imc.org Mon Jan 28 20:55:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJfhd-0005aq-WE for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 20:55:58 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJfhc-0003fn-97 for atompub-archive@lists.ietf.org; Mon, 28 Jan 2008 20:55:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0T1hCSe016747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 18:43:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0T1hCqf016745; Mon, 28 Jan 2008 18:43:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0T1hBmS016739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Jan 2008 18:43:11 -0700 (MST) (envelope-from brunet@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m0T1hAhm024710 for ; Mon, 28 Jan 2008 20:43:10 -0500 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0T1hALR062742 for ; Mon, 28 Jan 2008 18:43:10 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id m0T1hAXB011745 for ; Mon, 28 Jan 2008 18:43:10 -0700 Received: from d03nm116.boulder.ibm.com (d03nm116.boulder.ibm.com [9.17.195.142]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id m0T1hAWm011742 for ; Mon, 28 Jan 2008 18:43:10 -0700 To: atom-syntax@imc.org MIME-Version: 1.0 Subject: Atom and accessibility X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Pete Brunet Message-ID: Date: Mon, 28 Jan 2008 19:43:08 -0600 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 8.0|August 02, 2007) at 01/28/2008 18:43:09, Serialize complete at 01/28/2008 18:43:09 Content-Type: multipart/alternative; boundary="=_alternative 00097013862573DF_=" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multipart message in MIME format. --=_alternative 00097013862573DF_= Content-Type: text/plain; charset="US-ASCII" I am interesting in evaluating Atom to determine what the accessibility needs are. I'd limit this, at least for now, to enhancements to help blind screen reader users. I'd like to eventually develop a list of recommendations for improvement, e.g development of new technology or creating usage guidelines. My primary interest is in relation to the use of Atom in mashups, for example, a web page may start out being accessible by using W3C WCAG ( Web content Accessibility Guidelines, see http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via Atom it may become inaccessible. If you've done any research in this area or if you have pointers to background material I'd like to hear from you. I am starting at ground zero with respect to Atom (but have been in the accessibility field for many years) so it's likely that no information will be too basic :-) Should further discussion related to accessibility take place on this list or atom-protocol? Thanks, Pete Brunet IBM Accessibility Architecture and Development 11501 Burnet Road, MS 9022E004, Austin, TX 78758 Voice: (512) 838-4594, Cell: (512) 689-4155 Ionosphere: WS4G --=_alternative 00097013862573DF_= Content-Type: text/html; charset="US-ASCII"
I am interesting in evaluating Atom to determine what the accessibility needs are.  I'd limit this, at least for now, to enhancements to help blind screen reader users.  I'd like to eventually develop a list of recommendations for improvement, e.g development of new technology or creating usage guidelines.  My primary interest is in relation to the use of Atom in mashups, for example, a web page may start out being accessible by using W3C WCAG ( Web content Accessibility Guidelines, see http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via Atom it may become inaccessible.  If you've done any research in this area or if you have pointers to background material I'd like to hear from you.  I am starting at ground zero with respect to Atom (but have been in the accessibility field for many years) so it's likely that no information will be too basic :-)  

Should further discussion related to accessibility take place on this list or atom-protocol?

Thanks,
Pete Brunet
                                                                         
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G
 --=_alternative 00097013862573DF_=-- From owner-atom-syntax@mail.imc.org Tue Jan 29 00:39:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJjCQ-0006Oi-4K for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 00:39:58 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJjCN-0007kb-Pa for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 00:39:58 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0T5QWCt030787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 22:26:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0T5QWBV030786; Mon, 28 Jan 2008 22:26:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0T5QUfM030777 for ; Mon, 28 Jan 2008 22:26:31 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so1079559wra.13 for ; Mon, 28 Jan 2008 21:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=ZxbDF0H5akkfefaxjnkLW0EViJ0UKIuv3O9dHFy0ydA=; b=D0lE76TMJUQDPW3uAxxm1ElLvpQTRvo/8kuw6/jbdYqf/8oxp383mNWHrKUXmdCn5rc31ZAtd/ddhfKOTW/i1M3Vxx0EXOsb/huXtxW5a3eN7i/hIXSDD45ZlVKIsAfLmcvr4mDbv2K7OIRcx9A2ERHLSrthmft7m0eNcNsFWMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=GVI5NKf9FDm+/hGtDHFh6CL5v9cjeAQF2e4ljcRrmTrF/SAmzFdgQYjC6N04fD9Ha7BlMWRf0zn9xhzODclyiY7VmgU7xpozWlVCGe4ZRPupXlOS4Gwq6bhc8JyI5NgfuraKJRzapKMB7+/UiqXzQqep6JZ5qsArCDfb9H5wRQs= Received: by 10.151.15.3 with SMTP id s3mr2505072ybi.143.1201584389851; Mon, 28 Jan 2008 21:26:29 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a68sm10928611rnc.14.2008.01.28.21.26.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jan 2008 21:26:29 -0800 (PST) Message-ID: <479EB902.7000701@gmail.com> Date: Mon, 28 Jan 2008 21:26:26 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Pete Brunet CC: atom-syntax@imc.org Subject: Re: Atom and accessibility References: In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hey Pete, Glad to see this :-). There are several features of Atom that have been designed with accessibility in mind. 1. Explicitly typed text - title's, summary's, subtitle's, rights, and content are all explicitly typed as either plain text, html, xhtml, xml or some other media type 2. Required text content - title's are required for every entry and textual content in the form of either an atom:summary or atom:content element is required. It is possible for either of these to be empty, but the elements themselves are required, allowing applications to know explicitly whether or not text content has been provided. 3. Language tags - The use of xml:lang attributes allow the language for every piece of text to be explicitly declared. 4. Link titles - The atom:link element has an optional language-sensitive title attribute that is a rough analog to the html img tag's alt attribute. 5. Link href lang - The atom:link element specifies an hreflang attribute that identifies the language of the referenced resource. 6. Link types - The atom:link element specifies a type attribute that identifies the media type of the referenced resource 7. Accessible (x)html embedded in an atom text element or atom:content should continue to remain accessible within the Atom feed. There are a number of areas where accessibility is somewhat inadequate: 1. The atom:icon and atom:logo elements do not have title or type attributes. 2. Despite requirements for the use of atom:title, atom:summary and atom:content, it is possible for an entry to contain zero human-readable text It would be helpful if someone with a strong accessibility background could run some tests on a corpus of atom feeds to see what accessibility issues appear to be most common. As far as I am aware, no such analysis has ever been done. - James Pete Brunet wrote: > > I am interesting in evaluating Atom to determine what the accessibility > needs are. I'd limit this, at least for now, to enhancements to help > blind screen reader users. I'd like to eventually develop a list of > recommendations for improvement, e.g development of new technology or > creating usage guidelines. My primary interest is in relation to the > use of Atom in mashups, for example, a web page may start out being > accessible by using W3C WCAG ( Web content Accessibility Guidelines, see > http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via > Atom it may become inaccessible. If you've done any research in this > area or if you have pointers to background material I'd like to hear > from you. I am starting at ground zero with respect to Atom (but have > been in the accessibility field for many years) so it's likely that no > information will be too basic :-) > > Should further discussion related to accessibility take place on this > list or atom-protocol? > > Thanks, > *Pete Brunet* > > IBM Accessibility Architecture and Development > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > Voice: (512) 838-4594, Cell: (512) 689-4155 > Ionosphere: WS4G From retubert591@AndersonAir.Com Tue Jan 29 08:23:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJqQp-0006vl-8E for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 08:23:19 -0500 Received: from mediacom2.net8.nerim.net ([213.41.185.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJqQk-0001lI-IL for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 08:23:14 -0500 Received: (qmail 58339 invoked from network); Tue, 29 Jan 2008 14:22:31 +0100 Received: from unknown (HELO AndersonAir.Com) (72.201.136.62) by with SMTP; Tue, 29 Jan 2008 14:22:30 +0100 Received: from localhost.localdomain ( [126.163.160.3]) by AndersonAir.Com (8.13.1/8.13.1) with SMTP id LmpsXubh630878 for ; Tue, 29 Jan 2008 14:22:29 +0100 Message-Id: <763995128304.LmpsXubh630878@126391.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Tue, 29 Jan 2008 14:22:29 +0100 Date: Tue, 29 Jan 2008 14:22:29 +0100 To: atompub-archive@lists.ietf.org From: "retubert" Subject: rettef X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: retubert591@AndersonAir.Com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 http://www.ohpsphse.com/ Take 2 tablets a day, and gain 3-4 inches within a few short months. From Ashif-atnarisn@123-rejs.dk Tue Jan 29 10:22:35 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsIF-0007nH-Ps for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 10:22:35 -0500 Received: from host133-68-static.91-82-b.business.telecomitalia.it ([82.91.68.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsIF-0005aD-0o for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 10:22:35 -0500 Message-ID: <001101c8628a$c6839460$85445b52@FRANCO> From: "Ashif lepper" To: atompub-archive@lists.ietf.org Subject: Ever wondered what chicks look for? 83% of US college girls surveyed would prefer their boyfriends to have a larger instrument Date: Tue, 29 Jan 2008 16:22:35 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C86293.2847FC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----------=_NextPart_000_000D_01C86293.2847FC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Huge C0ck5 make girls wet Make yours a big one today ----------=_NextPart_000_000D_01C86293.2847FC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Huge C0ck5 make girls wet Make yours = a big one=20 today ----------=_NextPart_000_000D_01C86293.2847FC60-- From owner-atom-syntax@mail.imc.org Tue Jan 29 10:40:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsZz-0003Y7-7x for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 10:40:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJsZy-00031y-17 for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 10:40:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TFIGFw088538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 08:18:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TFIG2o088537; Tue, 29 Jan 2008 08:18:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TFIFb0088528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Jan 2008 08:18:16 -0700 (MST) (envelope-from brunet@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m0TEEoWV022198 for ; Tue, 29 Jan 2008 09:14:50 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0TFIEGJ085894 for ; Tue, 29 Jan 2008 08:18:14 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0TFIEEf025365 for ; Tue, 29 Jan 2008 08:18:14 -0700 Received: from d03nm116.boulder.ibm.com (d03nm116.boulder.ibm.com [9.17.195.142]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0TFIEti025312 for ; Tue, 29 Jan 2008 08:18:14 -0700 In-Reply-To: <479EB902.7000701@gmail.com> To: atom-syntax@imc.org MIME-Version: 1.0 Subject: Re: Atom and accessibility X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Pete Brunet Message-ID: Date: Tue, 29 Jan 2008 09:18:12 -0600 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 8.0|August 02, 2007) at 01/29/2008 08:18:13, Serialize complete at 01/29/2008 08:18:13 Content-Type: multipart/alternative; boundary="=_alternative 00540EF9862573DF_=" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 This is a multipart message in MIME format. --=_alternative 00540EF9862573DF_= Content-Type: text/plain; charset="US-ASCII" Thanks James, That's great input. I might be able to find someone to do the testing. Is there a corpus available that could be used? Regarding the two inadequacies you mentioned > 1. The atom:icon and atom:logo elements do not have title or type attributes. Is that being considered for a future version of Atom? > 2. Despite requirements for the use of atom:title, atom:summary and atom:content, it is possible for an entry to contain zero human-readable text Has anyone written (or started to write) accessibility guidelines? Pete Brunet IBM Accessibility Architecture and Development 11501 Burnet Road, MS 9022E004, Austin, TX 78758 Voice: (512) 838-4594, Cell: (512) 689-4155 Ionosphere: WS4G James M Snell Sent by: owner-atom-syntax@mail.imc.org 01/28/2008 11:26 PM To Pete Brunet/Austin/IBM@IBMUS cc atom-syntax@imc.org Subject Re: Atom and accessibility Hey Pete, Glad to see this :-). There are several features of Atom that have been designed with accessibility in mind. 1. Explicitly typed text - title's, summary's, subtitle's, rights, and content are all explicitly typed as either plain text, html, xhtml, xml or some other media type 2. Required text content - title's are required for every entry and textual content in the form of either an atom:summary or atom:content element is required. It is possible for either of these to be empty, but the elements themselves are required, allowing applications to know explicitly whether or not text content has been provided. 3. Language tags - The use of xml:lang attributes allow the language for every piece of text to be explicitly declared. 4. Link titles - The atom:link element has an optional language-sensitive title attribute that is a rough analog to the html img tag's alt attribute. 5. Link href lang - The atom:link element specifies an hreflang attribute that identifies the language of the referenced resource. 6. Link types - The atom:link element specifies a type attribute that identifies the media type of the referenced resource 7. Accessible (x)html embedded in an atom text element or atom:content should continue to remain accessible within the Atom feed. There are a number of areas where accessibility is somewhat inadequate: 1. The atom:icon and atom:logo elements do not have title or type attributes. 2. Despite requirements for the use of atom:title, atom:summary and atom:content, it is possible for an entry to contain zero human-readable text It would be helpful if someone with a strong accessibility background could run some tests on a corpus of atom feeds to see what accessibility issues appear to be most common. As far as I am aware, no such analysis has ever been done. - James Pete Brunet wrote: > > I am interesting in evaluating Atom to determine what the accessibility > needs are. I'd limit this, at least for now, to enhancements to help > blind screen reader users. I'd like to eventually develop a list of > recommendations for improvement, e.g development of new technology or > creating usage guidelines. My primary interest is in relation to the > use of Atom in mashups, for example, a web page may start out being > accessible by using W3C WCAG ( Web content Accessibility Guidelines, see > http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via > Atom it may become inaccessible. If you've done any research in this > area or if you have pointers to background material I'd like to hear > from you. I am starting at ground zero with respect to Atom (but have > been in the accessibility field for many years) so it's likely that no > information will be too basic :-) > > Should further discussion related to accessibility take place on this > list or atom-protocol? > > Thanks, > *Pete Brunet* > > IBM Accessibility Architecture and Development > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > Voice: (512) 838-4594, Cell: (512) 689-4155 > Ionosphere: WS4G --=_alternative 00540EF9862573DF_= Content-Type: text/html; charset="US-ASCII"
Thanks James, That's great input.  I might be able to find someone to do the testing.  Is there a corpus available that could be used?  Regarding the two inadequacies you mentioned

> 1. The atom:icon and atom:logo elements do not have title or type attributes.

Is that being considered for a future version of Atom?

> 2. Despite requirements for the use of atom:title, atom:summary and atom:content, it is possible for an entry to contain zero human-readable text

Has anyone written (or started to write) accessibility guidelines?

Pete Brunet
                                                                         
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G


James M Snell <jasnell@gmail.com>
Sent by: owner-atom-syntax@mail.imc.org

01/28/2008 11:26 PM

To
Pete Brunet/Austin/IBM@IBMUS
cc
atom-syntax@imc.org
Subject
Re: Atom and accessibility






Hey Pete,

Glad to see this :-). There are several features of Atom that have been
designed with accessibility in mind.

 1. Explicitly typed text - title's, summary's, subtitle's, rights,
    and content are all explicitly typed as either plain text, html,
    xhtml, xml or some other media type

 2. Required text content - title's are required for every entry and
    textual content in the form of either an atom:summary or
    atom:content element is required.  It is possible for either of
    these to be empty, but the elements themselves are required,
    allowing applications to know explicitly whether or not text
    content has been provided.

 3. Language tags - The use of xml:lang attributes allow the language
    for every piece of text to be explicitly declared.

 4. Link titles - The atom:link element has an optional
    language-sensitive title attribute that is a rough analog to the
    html img tag's alt attribute.

 5. Link href lang - The atom:link element specifies an hreflang
    attribute that identifies the language of the referenced resource.

 6. Link types - The atom:link element specifies a type attribute that
    identifies the media type of the referenced resource

 7. Accessible (x)html embedded in an atom text element or atom:content
    should continue to remain accessible within the Atom feed.

There are a number of areas where accessibility is somewhat inadequate:

 1. The atom:icon and atom:logo elements do not have title or type
    attributes.

 2. Despite requirements for the use of atom:title, atom:summary and
    atom:content, it is possible for an entry to contain zero
    human-readable text

It would be helpful if someone with a strong accessibility background
could run some tests on a corpus of atom feeds to see what accessibility
issues appear to be most common.  As far as I am aware, no such analysis
has ever been done.

- James

Pete Brunet wrote:
>
> I am interesting in evaluating Atom to determine what the accessibility
> needs are.  I'd limit this, at least for now, to enhancements to help
> blind screen reader users.  I'd like to eventually develop a list of
> recommendations for improvement, e.g development of new technology or
> creating usage guidelines.  My primary interest is in relation to the
> use of Atom in mashups, for example, a web page may start out being
> accessible by using W3C WCAG ( Web content Accessibility Guidelines, see
> http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via
> Atom it may become inaccessible.  If you've done any research in this
> area or if you have pointers to background material I'd like to hear
> from you.  I am starting at ground zero with respect to Atom (but have
> been in the accessibility field for many years) so it's likely that no
> information will be too basic :-)  
>
> Should further discussion related to accessibility take place on this
> list or atom-protocol?
>
> Thanks,
> *Pete Brunet*
>                                                                          
> IBM Accessibility Architecture and Development
> 11501 Burnet Road, MS 9022E004, Austin, TX 78758
> Voice: (512) 838-4594, Cell: (512) 689-4155
> Ionosphere: WS4G
--=_alternative 00540EF9862573DF_=-- From owner-atom-syntax@mail.imc.org Tue Jan 29 10:57:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJspn-0005c6-IP for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 10:57:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJspl-0003If-OH for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 10:57:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TFgLXI091321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 08:42:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TFgLTa091320; Tue, 29 Jan 2008 08:42:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TFgIGG091312 for ; Tue, 29 Jan 2008 08:42:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by an-out-0708.google.com with SMTP id c23so487818anc.44 for ; Tue, 29 Jan 2008 07:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=mxs/9A+2M5iFUpOLJg/KL6rOeJTQ4JXdssXazzH85nA=; b=WN7RzKXPMiSlBXq912Ic5RQWgaSmy5zXB9Xp0CSsQc9vvoG8SHLoWXEOfK8JiHSbK5OxjPz6afd9g/4VlesnqPGNL1v66v0rjOhUTHC/BBA+NfAJsw6bTHUd9v/jYDXzRbXDYloRTsV5xIUUF9WjUvFxBD/WvK6XDZGWjL2g2Ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=bNRyxiBfUI/3PKbR3RlZePd69p9i6DsA+J4/YAks6P/gpJBq20i24FiwjOrklEXgqS1SypF72mLNExro2y59r/nRMU7jLMAq4nlm6VMb0BIn6Bv58R4CGRiuldTNoxCNr+I3Js7NyJVtktztC2LGOjzrSxAc4khLikhlk48oyEg= Received: by 10.100.153.6 with SMTP id a6mr15041609ane.18.1201621337189; Tue, 29 Jan 2008 07:42:17 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 44sm2229736hsa.3.2008.01.29.07.42.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jan 2008 07:42:16 -0800 (PST) Message-ID: <479F4956.5020202@gmail.com> Date: Tue, 29 Jan 2008 07:42:14 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Pete Brunet CC: atom-syntax@imc.org Subject: Re: Atom and accessibility References: In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Pete Brunet wrote: > > Thanks James, That's great input. I might be able to find someone to do > the testing. Is there a corpus available that could be used? Regarding > the two inadequacies you mentioned > > > 1. The atom:icon and atom:logo elements do not have title or type > attributes. > > Is that being considered for a future version of Atom? > There are no future versions of Atom being considered :-). It would be possible to add the attributes as an extension, or to define alternative icon/logo link relations so the link's element type and title can be used. > > 2. Despite requirements for the use of atom:title, atom:summary and > atom:content, it is possible for an entry to contain zero human-readable > text > > Has anyone written (or started to write) accessibility guidelines? > Not that I am aware of. I, for one, would welcome such guidelines and would be willing to help write them up. - James > *Pete Brunet* > > IBM Accessibility Architecture and Development > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > Voice: (512) 838-4594, Cell: (512) 689-4155 > Ionosphere: WS4G > > > > *James M Snell * > Sent by: owner-atom-syntax@mail.imc.org > > 01/28/2008 11:26 PM > > > To > Pete Brunet/Austin/IBM@IBMUS > cc > atom-syntax@imc.org > Subject > Re: Atom and accessibility > > > > > > > > > > Hey Pete, > > Glad to see this :-). There are several features of Atom that have been > designed with accessibility in mind. > > 1. Explicitly typed text - title's, summary's, subtitle's, rights, > and content are all explicitly typed as either plain text, html, > xhtml, xml or some other media type > > 2. Required text content - title's are required for every entry and > textual content in the form of either an atom:summary or > atom:content element is required. It is possible for either of > these to be empty, but the elements themselves are required, > allowing applications to know explicitly whether or not text > content has been provided. > > 3. Language tags - The use of xml:lang attributes allow the language > for every piece of text to be explicitly declared. > > 4. Link titles - The atom:link element has an optional > language-sensitive title attribute that is a rough analog to the > html img tag's alt attribute. > > 5. Link href lang - The atom:link element specifies an hreflang > attribute that identifies the language of the referenced resource. > > 6. Link types - The atom:link element specifies a type attribute that > identifies the media type of the referenced resource > > 7. Accessible (x)html embedded in an atom text element or atom:content > should continue to remain accessible within the Atom feed. > > There are a number of areas where accessibility is somewhat inadequate: > > 1. The atom:icon and atom:logo elements do not have title or type > attributes. > > 2. Despite requirements for the use of atom:title, atom:summary and > atom:content, it is possible for an entry to contain zero > human-readable text > > It would be helpful if someone with a strong accessibility background > could run some tests on a corpus of atom feeds to see what accessibility > issues appear to be most common. As far as I am aware, no such analysis > has ever been done. > > - James > > Pete Brunet wrote: > > > > I am interesting in evaluating Atom to determine what the accessibility > > needs are. I'd limit this, at least for now, to enhancements to help > > blind screen reader users. I'd like to eventually develop a list of > > recommendations for improvement, e.g development of new technology or > > creating usage guidelines. My primary interest is in relation to the > > use of Atom in mashups, for example, a web page may start out being > > accessible by using W3C WCAG ( Web content Accessibility Guidelines, see > > http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via > > Atom it may become inaccessible. If you've done any research in this > > area or if you have pointers to background material I'd like to hear > > from you. I am starting at ground zero with respect to Atom (but have > > been in the accessibility field for many years) so it's likely that no > > information will be too basic :-) > > > > Should further discussion related to accessibility take place on this > > list or atom-protocol? > > > > Thanks, > > *Pete Brunet* > > > > IBM Accessibility Architecture and Development > > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > > Voice: (512) 838-4594, Cell: (512) 689-4155 > > Ionosphere: WS4G > > From owner-atom-syntax@mail.imc.org Tue Jan 29 11:30:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtLi-0006r9-3Z for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 11:30:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJtLf-000410-Pa for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 11:30:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TG8fTW093629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 09:08:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TG8fPW093628; Tue, 29 Jan 2008 09:08:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TG8eYJ093621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jan 2008 09:08:40 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.170.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 455BED05A2 for ; Tue, 29 Jan 2008 11:08:38 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <479EB902.7000701@gmail.com> Subject: RE: Atom and accessibility Date: Tue, 29 Jan 2008 08:08:35 -0800 Message-ID: <000601c86291$36d61980$0501a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achii1vJ39xceQanSbySqZGudKEgjwAADE0g Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Pete Brunet wrote: > James Snell wrote: > > 1. The atom:icon and atom:logo elements do not have title or type attributes. > > Is that being considered for a future version of Atom? 1. and could be considered the accessible alternative for the icon and logo. Most modern accessibility guidelines recommend against providing alternative text for logos and icons when that alternative text would significantly duplicate content available elsewhere in the document. A title attribute is a bad idea because human-readable text shouldn't be represented with attributes. If it is needed then it should be a text construct. > > 2. Despite requirements for the use of atom:title, atom:summary and atom:content, > > it is possible for an entry to contain zero human-readable text That is true, but now there are Atom applications where entries are meant to be consumed only by software. An example is http://ietfreport.isoc.org/idref/draft-nottingham-http-cache-channels/. An annotation that indicates "this is not intended to be read by people" would be an accessibility improvement for such documents. > Has anyone written (or started to write) accessibility guidelines? I don't know of any. For media resources (images, video), I would like some guidelines about how to provide accessible alternatives. There are several possibilities already: 1. Many media file formats allow accessible alternatives (descriptive text, captions, alternate audio tracks for non-sighted users, transcripts) to be embedded directly in the media file. 2. An entry can provide use to link to accessible alternatives. This would probably be most useful for media link entries or enclosures (any entry with non-textual content, or out-of-line content). However, we might need separate HTML alternatives for each disability (learning disabilities, vision impairment, hearing impairment), but this isn't really allowed when using ; See section 4.1.2. Due to that limitation, an alternative link relation may be needed. Or, a set of link relations may be useful that help guide users to the correct alternative based on their impairment. For example, rel="large-print", rel="blind", rel="deaf", rel="transcript", rel="captioned". 3. Media link entries or enclosure entries can provide accessible alternatives inline, possible using foreign markup. For example, a media link entry for an image could include alternative text for blind users in the element. However, I think this is bad practice, because it overloads the meaning of , but it is probably better than nothing. Guidelines for choosing between these mechanisms would be very useful. Also, a mechanism for detecting when accessible alternatives might be out of date would be useful. For example, if somebody updates a video, but didn't update the transcript, that is information that would be helpful for a non-sighted user. if I was blind, I would probably want the ability to subscribe to a feed where the full content of the transcripts/alternative text was inline, instead of linked to using . - Brian From owner-atom-syntax@mail.imc.org Tue Jan 29 12:02:10 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJtqc-0005Jq-60 for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:02:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJtqa-0004vO-Cg for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:02:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TGeJc0097713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 09:40:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TGeJs3097712; Tue, 29 Jan 2008 09:40:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TGeFkR097701 for ; Tue, 29 Jan 2008 09:40:18 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so1664933rvf.34 for ; Tue, 29 Jan 2008 08:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=+bLtAsFgUonxVZrz8EsCDTl90VUVjevHd/W0Y5Pa3Hs=; b=oMbO95MR/vGAq554DANFfUfo6boqKFO00Yc0lJ0Xe33qVvXnO8pow1s7H/4go2Q7d2oK3d9wcIwaOAFlh1fzuarVBkJtAqJJtpW5yRAPGH7CNNDKRXJFnPKGtaABPIUTdfOg75rOYUF4vG+3/ZagzFCh1+EqDzDe4s9xiMj0/nE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=wApjuDERJ+fhJiiNfxrpreKYRJoUlJy/Y7MZdyTdabMP4yZOCa+MT+oJZy9TxMyxmfJJy5jNnKx7QkU4PqrVanjbDoPkq0D+mhuUIvJ9JxPF3HY6ZclvIVOek3ReJApJhiwtmARQWwAaf+0nGjU+gCJRidfPfyPVe66hj8KB+vk= Received: by 10.140.177.15 with SMTP id z15mr2657699rve.70.1201624815509; Tue, 29 Jan 2008 08:40:15 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id m10sm12124276rnd.15.2008.01.29.08.40.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jan 2008 08:40:12 -0800 (PST) Message-ID: <479F56E3.9000008@gmail.com> Date: Tue, 29 Jan 2008 08:40:03 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Brian Smith CC: "'atom-syntax'" Subject: Re: Atom and accessibility References: <479EB902.7000701@gmail.com> <000601c86291$36d61980$0501a8c0@T60> In-Reply-To: <000601c86291$36d61980$0501a8c0@T60> X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Brian Smith wrote: > Pete Brunet wrote: >> James Snell wrote: >>> 1. The atom:icon and atom:logo elements do not have title or type > attributes. >> Is that being considered for a future version of Atom? > > 1. and could be considered the accessible > alternative for the icon and logo. Most modern accessibility guidelines > recommend against providing alternative text for logos and icons when > that alternative text would significantly duplicate content available > elsewhere in the document. > > A title attribute is a bad idea because human-readable text shouldn't be > represented with attributes. If it is needed then it should be a text > construct. > True, however, while unlikely, the title and summary can each contain complex markup. If accessibility guidelines were to suggest using those elements as the alternate text for the icon/logo, then the guidelines would need to suggest appropriate content restrictions for each or else specify a processing model so markup can be dealt with appropriately. >>> 2. Despite requirements for the use of atom:title, atom:summary and > atom:content, >>> it is possible for an entry to contain zero human-readable text > > That is true, but now there are Atom applications where entries are > meant to be consumed only by software. An example is > http://ietfreport.isoc.org/idref/draft-nottingham-http-cache-channels/. > An annotation that indicates "this is not intended to be read by people" > would be an accessibility improvement for such documents. > Interesting idea. >> Has anyone written (or started to write) accessibility guidelines? > > I don't know of any. For media resources (images, video), I would like > some guidelines about how to provide accessible alternatives. There are > several possibilities already: > > 1. Many media file formats allow accessible alternatives (descriptive > text, captions, alternate audio tracks for non-sighted users, > transcripts) to be embedded directly in the media file. > > 2. An entry can provide use to link to > accessible alternatives. This would probably be most useful for media > link entries or enclosures (any entry with non-textual content, or > out-of-line content). However, we might need separate HTML alternatives > for each disability (learning disabilities, vision impairment, hearing > impairment), but this isn't really allowed when using rel='alternative'>; See section 4.1.2. Due to that limitation, an > alternative link relation may be needed. Or, a set of link relations may > be useful that help guide users to the correct alternative based on > their impairment. For example, rel="large-print", rel="blind", > rel="deaf", rel="transcript", rel="captioned". > > 3. Media link entries or enclosure entries can provide accessible > alternatives inline, possible using foreign markup. For example, a media > link entry for an image could include alternative text for blind users > in the element. However, I think this is bad practice, > because it overloads the meaning of , but it is probably > better than nothing. > Actually, this is one of the main reasons why atom:summary is provided. If the atom:content has binary content, or if it uses the src attribute, the atom:summary element needs to be used to provide a human readable description. It definitely is not bad practice. - James > Guidelines for choosing between these mechanisms would be very useful. > Also, a mechanism for detecting when accessible alternatives might be > out of date would be useful. For example, if somebody updates a video, > but didn't update the transcript, that is information that would be > helpful for a non-sighted user. > > if I was blind, I would probably want the ability to subscribe to a feed > where the full content of the transcripts/alternative text was inline, > instead of linked to using . > > - Brian > > From owner-atom-syntax@mail.imc.org Tue Jan 29 12:15:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJu3W-0007dB-81 for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:15:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJu3U-0005Kb-PG for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:15:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TGrJu3098752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 09:53:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TGrJRc098751; Tue, 29 Jan 2008 09:53:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TGrI7J098744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Jan 2008 09:53:19 -0700 (MST) (envelope-from brunet@us.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m0TGrGlF025545 for ; Tue, 29 Jan 2008 11:53:16 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0TGr5VH024840 for ; Tue, 29 Jan 2008 09:53:07 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0TGr23G002914 for ; Tue, 29 Jan 2008 09:53:02 -0700 Received: from d03nm116.boulder.ibm.com (d03nm116.boulder.ibm.com [9.17.195.142]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0TGqrMV001897 for ; Tue, 29 Jan 2008 09:52:53 -0700 In-Reply-To: <479F4956.5020202@gmail.com> To: James M Snell Cc: atom-syntax@imc.org, owner-atom-syntax@mail.imc.org MIME-Version: 1.0 Subject: Re: Atom and accessibility X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Pete Brunet Message-ID: Date: Tue, 29 Jan 2008 10:52:51 -0600 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 8.0|August 02, 2007) at 01/29/2008 09:52:52, Serialize complete at 01/29/2008 09:52:52 Content-Type: multipart/alternative; boundary="=_alternative 005CB915862573DF_=" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e This is a multipart message in MIME format. --=_alternative 005CB915862573DF_= Content-Type: text/plain; charset="US-ASCII" > I might be able to find someone to do the testing. Is there a corpus available that could be used? Since James didn't answer this - does anyone else have suggestions for a corpus? > It would be possible to add the attributes as an extension, or to define alternative icon/logo link relations so the link's element type and title can be used. Is this a issue that would best be explored in atom-protocol? Pete Brunet IBM Accessibility Architecture and Development 11501 Burnet Road, MS 9022E004, Austin, TX 78758 Voice: (512) 838-4594, Cell: (512) 689-4155 Ionosphere: WS4G James M Snell Sent by: owner-atom-syntax@mail.imc.org 01/29/2008 09:42 AM To Pete Brunet/Austin/IBM@IBMUS cc atom-syntax@imc.org Subject Re: Atom and accessibility Pete Brunet wrote: > > Thanks James, That's great input. I might be able to find someone to do > the testing. Is there a corpus available that could be used? Regarding > the two inadequacies you mentioned > > > 1. The atom:icon and atom:logo elements do not have title or type > attributes. > > Is that being considered for a future version of Atom? > There are no future versions of Atom being considered :-). It would be possible to add the attributes as an extension, or to define alternative icon/logo link relations so the link's element type and title can be used. > > 2. Despite requirements for the use of atom:title, atom:summary and > atom:content, it is possible for an entry to contain zero human-readable > text > > Has anyone written (or started to write) accessibility guidelines? > Not that I am aware of. I, for one, would welcome such guidelines and would be willing to help write them up. - James > *Pete Brunet* > > IBM Accessibility Architecture and Development > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > Voice: (512) 838-4594, Cell: (512) 689-4155 > Ionosphere: WS4G > > > > *James M Snell * > Sent by: owner-atom-syntax@mail.imc.org > > 01/28/2008 11:26 PM > > > To > Pete Brunet/Austin/IBM@IBMUS > cc > atom-syntax@imc.org > Subject > Re: Atom and accessibility > > > > > > > > > > Hey Pete, > > Glad to see this :-). There are several features of Atom that have been > designed with accessibility in mind. > > 1. Explicitly typed text - title's, summary's, subtitle's, rights, > and content are all explicitly typed as either plain text, html, > xhtml, xml or some other media type > > 2. Required text content - title's are required for every entry and > textual content in the form of either an atom:summary or > atom:content element is required. It is possible for either of > these to be empty, but the elements themselves are required, > allowing applications to know explicitly whether or not text > content has been provided. > > 3. Language tags - The use of xml:lang attributes allow the language > for every piece of text to be explicitly declared. > > 4. Link titles - The atom:link element has an optional > language-sensitive title attribute that is a rough analog to the > html img tag's alt attribute. > > 5. Link href lang - The atom:link element specifies an hreflang > attribute that identifies the language of the referenced resource. > > 6. Link types - The atom:link element specifies a type attribute that > identifies the media type of the referenced resource > > 7. Accessible (x)html embedded in an atom text element or atom:content > should continue to remain accessible within the Atom feed. > > There are a number of areas where accessibility is somewhat inadequate: > > 1. The atom:icon and atom:logo elements do not have title or type > attributes. > > 2. Despite requirements for the use of atom:title, atom:summary and > atom:content, it is possible for an entry to contain zero > human-readable text > > It would be helpful if someone with a strong accessibility background > could run some tests on a corpus of atom feeds to see what accessibility > issues appear to be most common. As far as I am aware, no such analysis > has ever been done. > > - James > > Pete Brunet wrote: > > > > I am interesting in evaluating Atom to determine what the accessibility > > needs are. I'd limit this, at least for now, to enhancements to help > > blind screen reader users. I'd like to eventually develop a list of > > recommendations for improvement, e.g development of new technology or > > creating usage guidelines. My primary interest is in relation to the > > use of Atom in mashups, for example, a web page may start out being > > accessible by using W3C WCAG ( Web content Accessibility Guidelines, see > > http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via > > Atom it may become inaccessible. If you've done any research in this > > area or if you have pointers to background material I'd like to hear > > from you. I am starting at ground zero with respect to Atom (but have > > been in the accessibility field for many years) so it's likely that no > > information will be too basic :-) > > > > Should further discussion related to accessibility take place on this > > list or atom-protocol? > > > > Thanks, > > *Pete Brunet* > > > > IBM Accessibility Architecture and Development > > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > > Voice: (512) 838-4594, Cell: (512) 689-4155 > > Ionosphere: WS4G > > --=_alternative 005CB915862573DF_= Content-Type: text/html; charset="US-ASCII"
> I might be able to find someone to do the testing.  Is there a corpus available that could be used?
Since James didn't answer this - does anyone else have suggestions for a corpus?

> It would be possible to add the attributes as an extension, or to define alternative icon/logo link relations so the link's element type and title can be used.
Is this a issue that would best be explored in atom-protocol?

Pete Brunet
                                                                         
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G


James M Snell <jasnell@gmail.com>
Sent by: owner-atom-syntax@mail.imc.org

01/29/2008 09:42 AM

To
Pete Brunet/Austin/IBM@IBMUS
cc
atom-syntax@imc.org
Subject
Re: Atom and accessibility








Pete Brunet wrote:
>
> Thanks James, That's great input.  I might be able to find someone to do
> the testing.  Is there a corpus available that could be used?  Regarding
> the two inadequacies you mentioned
>
>  > 1. The atom:icon and atom:logo elements do not have title or type
> attributes.
>
> Is that being considered for a future version of Atom?
>

There are no future versions of Atom being considered :-).  It would be
possible to add the attributes as an extension, or to define alternative
icon/logo link relations so the link's element type and title can be used.

>  > 2. Despite requirements for the use of atom:title, atom:summary and
> atom:content, it is possible for an entry to contain zero human-readable
> text
>
> Has anyone written (or started to write) accessibility guidelines?
>

Not that I am aware of.  I, for one, would welcome such guidelines and
would be willing to help write them up.

- James

> *Pete Brunet*
>                                                                          
> IBM Accessibility Architecture and Development
> 11501 Burnet Road, MS 9022E004, Austin, TX 78758
> Voice: (512) 838-4594, Cell: (512) 689-4155
> Ionosphere: WS4G
>
>
>
> *James M Snell <jasnell@gmail.com>*
> Sent by: owner-atom-syntax@mail.imc.org
>
> 01/28/2008 11:26 PM
>
>                  
> To
>                  Pete Brunet/Austin/IBM@IBMUS
> cc
>                  atom-syntax@imc.org
> Subject
>                  Re: Atom and accessibility
>
>
>                  
>
>
>
>
>
>
> Hey Pete,
>
> Glad to see this :-). There are several features of Atom that have been
> designed with accessibility in mind.
>
>  1. Explicitly typed text - title's, summary's, subtitle's, rights,
>     and content are all explicitly typed as either plain text, html,
>     xhtml, xml or some other media type
>
>  2. Required text content - title's are required for every entry and
>     textual content in the form of either an atom:summary or
>     atom:content element is required.  It is possible for either of
>     these to be empty, but the elements themselves are required,
>     allowing applications to know explicitly whether or not text
>     content has been provided.
>
>  3. Language tags - The use of xml:lang attributes allow the language
>     for every piece of text to be explicitly declared.
>
>  4. Link titles - The atom:link element has an optional
>     language-sensitive title attribute that is a rough analog to the
>     html img tag's alt attribute.
>
>  5. Link href lang - The atom:link element specifies an hreflang
>     attribute that identifies the language of the referenced resource.
>
>  6. Link types - The atom:link element specifies a type attribute that
>     identifies the media type of the referenced resource
>
>  7. Accessible (x)html embedded in an atom text element or atom:content
>     should continue to remain accessible within the Atom feed.
>
> There are a number of areas where accessibility is somewhat inadequate:
>
>  1. The atom:icon and atom:logo elements do not have title or type
>     attributes.
>
>  2. Despite requirements for the use of atom:title, atom:summary and
>     atom:content, it is possible for an entry to contain zero
>     human-readable text
>
> It would be helpful if someone with a strong accessibility background
> could run some tests on a corpus of atom feeds to see what accessibility
> issues appear to be most common.  As far as I am aware, no such analysis
> has ever been done.
>
> - James
>
> Pete Brunet wrote:
>  >
>  > I am interesting in evaluating Atom to determine what the accessibility
>  > needs are.  I'd limit this, at least for now, to enhancements to help
>  > blind screen reader users.  I'd like to eventually develop a list of
>  > recommendations for improvement, e.g development of new technology or
>  > creating usage guidelines.  My primary interest is in relation to the
>  > use of Atom in mashups, for example, a web page may start out being
>  > accessible by using W3C WCAG ( Web content Accessibility Guidelines, see
>  > http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via
>  > Atom it may become inaccessible.  If you've done any research in this
>  > area or if you have pointers to background material I'd like to hear
>  > from you.  I am starting at ground zero with respect to Atom (but have
>  > been in the accessibility field for many years) so it's likely that no
>  > information will be too basic :-)  
>  >
>  > Should further discussion related to accessibility take place on this
>  > list or atom-protocol?
>  >
>  > Thanks,
>  > *Pete Brunet*
>  >                                                                          
>  > IBM Accessibility Architecture and Development
>  > 11501 Burnet Road, MS 9022E004, Austin, TX 78758
>  > Voice: (512) 838-4594, Cell: (512) 689-4155
>  > Ionosphere: WS4G
>
>


--=_alternative 005CB915862573DF_=-- From owner-atom-syntax@mail.imc.org Tue Jan 29 12:21:36 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJu9Q-0005e2-UY for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:21:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJu9Q-0005VV-Dw for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:21:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TH5D9i099875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 10:05:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TH5DL9099874; Tue, 29 Jan 2008 10:05:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TH5CXw099868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jan 2008 10:05:13 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.170.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C3A48D05B0 for ; Tue, 29 Jan 2008 12:05:11 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <479EB902.7000701@gmail.com> <000601c86291$36d61980$0501a8c0@T60> <479F56E3.9000008@gmail.com> Subject: RE: Atom and accessibility Date: Tue, 29 Jan 2008 09:05:12 -0800 Message-ID: <001401c86299$1ce558d0$0501a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <479F56E3.9000008@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achilfy9WXvmDcZEQSCz87QXmUV8cgAAGCOw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 James M Snell wrote: > True, however, while unlikely, the title and summary can each > contain complex markup. If accessibility guidelines were to > suggest using those elements as the alternate text for the > icon/logo, then the guidelines would need to suggest > appropriate content restrictions for each or else specify a > processing model so markup can be dealt with appropriately. Right. Restrictions on titles and summaries are needed even for users without disabilities, like we discussed a while back when we were debating whether Atom processors should support HTML/XHTML content in titles. > > 3. Media link entries or enclosure entries can provide accessible > > alternatives inline, possible using foreign markup. For example, a > > media link entry for an image could include alternative > > text for blind users in the element. However, I > > think this is bad practice, because it overloads the meaning of > > , but it is probably better than nothing. > > Actually, this is one of the main reasons why atom:summary is > provided. > If the atom:content has binary content, or if it uses the > src attribute, the atom:summary element needs to be used to > provide a human readable description. It definitely is not > bad practice. Let's say that the media resource is a chart. A reasonable summary might be "A rough projection of annual sales, based on sales through July 17th. Contact your department manager if you have questions." An (accessible) alternative would be a HTML table with the data that was used for the chart. A feed reader or editor is likely to provide only a limited amount of space for the summary (see FeedDeamon for example), which makes viewing a table embedded into the summary difficult. For a variety of reasons, summaries usually need to be short, but accessible alternatives may not be compact. Plus, atom:summary cannot be used to provide multiple accessible alternatives for one resource, which is needed to handle different disabilities. For those reasons, atom:summary should be used only as a fallback when no accessible alternative is available. - Brian From owner-atom-syntax@mail.imc.org Tue Jan 29 12:37:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJuP2-0003iY-TO for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:37:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJuP1-0005vV-VJ for atompub-archive@lists.ietf.org; Tue, 29 Jan 2008 12:37:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0THEkp6001162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 10:14:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0THEkW9001161; Tue, 29 Jan 2008 10:14:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0THEj1v001141 for ; Tue, 29 Jan 2008 10:14:45 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id r21so1559094wxc.28 for ; Tue, 29 Jan 2008 09:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=gz/Mt6+oX0mJ3+011m6a3HFotuRE9pSHjrMBzr/g0ms=; b=a4FJ1jw3JIIT+RIow/fXfdF1iVnf3bMal535KAejuwBx31y5R5Ly0pv8p/FXvWEGgHzO+CFZHxWBELvsu/O6i2w2+YQDZDSod+2i2VGrO3+9kunhf4TDmhHLi6T7mMGu/nrWXiVCb1jbNWk92NOr8DZ4RrLQpiGajH1PtdMCJ0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=fMPP0VGrKGmaf11Cy9LrdlUxjjjNweYzdl3TQn5D5m5m8LwInPqn4NVWRSWBTGUHOYykoBoj8Kqa5IdxLAMMWtCl+WP59Oukb93b3xImatwvEuIbOug1p8qqPFfrcpZRWb/ksW/bL44+5ICLumj2P4iveyCLe86c5RnLm+VEN0o= Received: by 10.141.129.14 with SMTP id g14mr4546347rvn.274.1201626883655; Tue, 29 Jan 2008 09:14:43 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id i33sm12267086rng.3.2008.01.29.09.14.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jan 2008 09:14:41 -0800 (PST) Message-ID: <479F5EFA.4020305@gmail.com> Date: Tue, 29 Jan 2008 09:14:34 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Pete Brunet CC: atom-syntax@imc.org, owner-atom-syntax@mail.imc.org Subject: Re: Atom and accessibility References: In-Reply-To: X-Enigmail-Version: 0.95.6 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Pete Brunet wrote: > > > I might be able to find someone to do the testing. Is there a corpus > available that could be used? > Since James didn't answer this - does anyone else have suggestions for a > corpus? > ...didn't answered it yet :-) There are quite a few atom feeds available. One immediate resource that is readily available to you would be any of the 100k+ feeds published by the ibm internal blog server. > > It would be possible to add the attributes as an extension, or to > define alternative icon/logo link relations so the link's element type > and title can be used. > Is this a issue that would best be explored in atom-protocol? > No, here is better. - James > *Pete Brunet* > > IBM Accessibility Architecture and Development > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > Voice: (512) 838-4594, Cell: (512) 689-4155 > Ionosphere: WS4G > > > > *James M Snell * > Sent by: owner-atom-syntax@mail.imc.org > > 01/29/2008 09:42 AM > > > To > Pete Brunet/Austin/IBM@IBMUS > cc > atom-syntax@imc.org > Subject > Re: Atom and accessibility > > > > > > > > > > > > Pete Brunet wrote: > > > > Thanks James, That's great input. I might be able to find someone to do > > the testing. Is there a corpus available that could be used? Regarding > > the two inadequacies you mentioned > > > > > 1. The atom:icon and atom:logo elements do not have title or type > > attributes. > > > > Is that being considered for a future version of Atom? > > > > There are no future versions of Atom being considered :-). It would be > possible to add the attributes as an extension, or to define alternative > icon/logo link relations so the link's element type and title can be used. > > > > 2. Despite requirements for the use of atom:title, atom:summary and > > atom:content, it is possible for an entry to contain zero human-readable > > text > > > > Has anyone written (or started to write) accessibility guidelines? > > > > Not that I am aware of. I, for one, would welcome such guidelines and > would be willing to help write them up. > > - James > > > *Pete Brunet* > > > > IBM Accessibility Architecture and Development > > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > > Voice: (512) 838-4594, Cell: (512) 689-4155 > > Ionosphere: WS4G > > > > > > > > *James M Snell * > > Sent by: owner-atom-syntax@mail.imc.org > > > > 01/28/2008 11:26 PM > > > > > > To > > Pete Brunet/Austin/IBM@IBMUS > > cc > > atom-syntax@imc.org > > Subject > > Re: Atom and accessibility > > > > > > > > > > > > > > > > > > > > Hey Pete, > > > > Glad to see this :-). There are several features of Atom that have been > > designed with accessibility in mind. > > > > 1. Explicitly typed text - title's, summary's, subtitle's, rights, > > and content are all explicitly typed as either plain text, html, > > xhtml, xml or some other media type > > > > 2. Required text content - title's are required for every entry and > > textual content in the form of either an atom:summary or > > atom:content element is required. It is possible for either of > > these to be empty, but the elements themselves are required, > > allowing applications to know explicitly whether or not text > > content has been provided. > > > > 3. Language tags - The use of xml:lang attributes allow the language > > for every piece of text to be explicitly declared. > > > > 4. Link titles - The atom:link element has an optional > > language-sensitive title attribute that is a rough analog to the > > html img tag's alt attribute. > > > > 5. Link href lang - The atom:link element specifies an hreflang > > attribute that identifies the language of the referenced resource. > > > > 6. Link types - The atom:link element specifies a type attribute that > > identifies the media type of the referenced resource > > > > 7. Accessible (x)html embedded in an atom text element or atom:content > > should continue to remain accessible within the Atom feed. > > > > There are a number of areas where accessibility is somewhat inadequate: > > > > 1. The atom:icon and atom:logo elements do not have title or type > > attributes. > > > > 2. Despite requirements for the use of atom:title, atom:summary and > > atom:content, it is possible for an entry to contain zero > > human-readable text > > > > It would be helpful if someone with a strong accessibility background > > could run some tests on a corpus of atom feeds to see what accessibility > > issues appear to be most common. As far as I am aware, no such analysis > > has ever been done. > > > > - James > > > > Pete Brunet wrote: > > > > > > I am interesting in evaluating Atom to determine what the > accessibility > > > needs are. I'd limit this, at least for now, to enhancements to help > > > blind screen reader users. I'd like to eventually develop a list of > > > recommendations for improvement, e.g development of new technology or > > > creating usage guidelines. My primary interest is in relation to the > > > use of Atom in mashups, for example, a web page may start out being > > > accessible by using W3C WCAG ( Web content Accessibility > Guidelines, see > > > http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating > content via > > > Atom it may become inaccessible. If you've done any research in this > > > area or if you have pointers to background material I'd like to hear > > > from you. I am starting at ground zero with respect to Atom (but have > > > been in the accessibility field for many years) so it's likely that no > > > information will be too basic :-) > > > > > > Should further discussion related to accessibility take place on this > > > list or atom-protocol? > > > > > > Thanks, > > > *Pete Brunet* > > > > > > > IBM Accessibility Architecture and Development > > > 11501 Burnet Road, MS 9022E004, Austin, TX 78758 > > > Voice: (512) 838-4594, Cell: (512) 689-4155 > > > Ionosphere: WS4G > > > > > > From reservation@freenet.de Wed Jan 30 02:42:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7aN-0004oX-E6 for atompub-archive@megatron.ietf.org; Wed, 30 Jan 2008 02:42:19 -0500 Received: from [85.106.162.83] (helo=mail.anatravel.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JK7aM-0002Fb-Cj for atompub-archive@megatron.ietf.org; Wed, 30 Jan 2008 02:42:19 -0500 Received: from mail.anatravel.org[127.0.0.1] by mail.anatravel.org[127.0.0.1] (SMTPD32); Wed, 30 Jan 2008 09:42:09 +0200 Organization: Air Turkey, ein Spezialveranstalter. Reply-To: mail@air-turkey.com Message-ID: From: "Air Turkey, ein Spezialveranstalter." To: Subject: Air Turkey, ein Spezialveranstalter. Date: Wed, 30 Jan 2008 09:38:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Sehr geehrte Damen und Herren=2E Air Turkey ist in Istanbul-Izmir-Antalya ein = Spezialveranstalter.www.air-turkey.com=20 Air Turkey spezialisiert f=FCr ihre = Fluege-Chartermiete,Spezialreisen,Hotels-Gruppenreisen von Kultur und=20 Bildungsreisen.Fuer Vereinen,Sportgruppen,Kirchen=2E Wir sind spezialisiert auch auf Individualreisen f=FCr Familien und = Familiefreizeiten=2E *Kultur Reisen f=FCr alle Gebiete Tuerkei=2E *Badeurlaub Hotel,s fuer Familien,Nur 5 Sterne All Inclusiv Hotels=2E *Istanbul Reisen f=FCr die Gruppen=2E *Nur Flug fuer alle Destination der Tuerkei=2E *Sport Reisen als Trainingslagern=2E Wir w=FCrden auch gern ihre Anfragen beantworten=2E Mit herzlichen Gr=FCssen=2E Air Turkey Team=2E mail@air-turkey.com ********************************* ANBEI FINDEN SIE UNSEREN FRUEHJAHR und HERBST 2008 SONDERANGEBOTE.(Ab = Z=FCrich,Wien Frankfurt-Muenchen-Dusseldorf und Stuttgart) ********************************** F=FCr Fruehjahr und Herbst 2008 offerieren wir Ihnen ein preislich = unschlagbares Angebot an der t=FCrkischen Riviera Side-Antalya und Belek. In 5 * Sterne-Hotel mit = Ultra All=20 Inclusive Service. S=E4mtlich Hotels im Angebot sind feine Strandhotels = direkt am Meer und mit denselben Preisen. Alle Zimmer haben Meerblick.=20 Unsere Fluege sind Ab Z=FCrich,Wien Frankfurt-Muenchen , Stuttgart und = Dusseldorf=2E Im Falle Ihrer Reservation bitten wir Sie h=F6flich, uns die Namen und = Anschriften der Reiseteilnehmer genau mitzuteilen=2E =20 Lassen Sie sich in einem der aufgef=FChrten 5* Hotel verw=F6hnen und = geniessen Sie Ihren Urlaub ohne grossen Touristenrummel=2E =20 Folgende Hotels stehen zur Verf=FCgung: S=FCral Saray Hotel Colakli-Side www.sural.com.tr Lares Park Hotel Antalya Lara www.laresparkhotel.com Fame Residence Antalya Lara www.famehotels.com Club Hotel Sera Antalya Lara www.clubhotelsera.com.tr Vera Club Mare Belek www.veraparadiso.com=20 Hotel Zena 5* Camyuva Kemer :www.zenaresort.com.tr Hotel Galeri 5* Okurcalar Alanya: www.galerihotel.com Unsere Inklusive-Leistungen: - Hin- und Rueckflug - Flughafentaxen und Sicherheitsgebuehren=2E - Transfers Flughafen - Hotel - Flughafen - Uebernachtungen in 5* Sterne Hotel Ihrer Wahl (All inklusive) - Begruessungs-Cocktail und fakultativer Antalya Ausflug - Deutschsprachige Reiseleitung=20 Reisetermine: 14.Maerz bis 21.Maerz 2008 Euro 490 21.Maerz bis 28.Maerz 2008 Euro 490 28.Maerz bis 04. April 2008 Euro 490 04. April bis 11. April 2008 Euro 490 11. April bis 18. April 2008 Euro 490 18. April bis 25. April 2008 Euro 490 25. April bis 02. Mai 2008 Euro 490 02 Mai bis 09. Mai 2008 Euro 490 09 Mai bis 16. Mai 2008 Euro 490 16 Mai bis 23. Mai 2008 Euro 490 ***************************************** 26 Setember bis 03 Oktpber 2008 Euro 490 26 Setember bis 03 Oktober 2008 Euro 490 03 Oktober bis 10 Oktpber 2008 Euro 490 10 Oktober bis 17 Oktpber 2008 Euro 490 17 Oktober bis 24 Oktpber 2008 Euro 490 24 Oktober bis 31 Oktpber 2008 Euro 490 Kinder von 0 - 2 Jahren sind frei, 2 - 14 Jahren 70 % des Preises=2E Sie haben diese Email unaufgefordert bekommen=2E Wenn Sie keine Mails von uns moechten klicken Sie bitte auf den Link: www.air-turkey.com/unsubscribe.htm From owner-atom-syntax@mail.imc.org Wed Jan 30 16:47:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKmP-0001pY-KF for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 16:47:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKmP-0003O9-5J for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 16:47:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULWlDg032681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 14:32:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ULWluu032680; Wed, 30 Jan 2008 14:32:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULWjfZ032668 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 14:32:47 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.162] (helo=pepper.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKKY0-0001BR-Ve for atom-syntax@imc.org; Wed, 30 Jan 2008 22:32:44 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by pepper.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKKY0-0002Sw-Kq for atom-syntax@imc.org; Wed, 30 Jan 2008 22:32:44 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: Status of the wrapper Date: Wed, 30 Jan 2008 22:31:09 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200801302231.09548.aleksandersen+atomlist@runbox.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0ULWlfY032674 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0ULWlDg032681 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi emailing list, (message contains Unicode characters) I am curious about the status of the required
container when=20 including xhtml in text constructs. With it be changed to become optional= =20 instead? The below example never made much sense to me. =E2=80=A6 This is a summary paragraph. =E2=80=A6 Instead I am currently using a =E2=80=98hack=E2=80=99 which involves decl= aring the type as=20 application/xhtml+xml instead of xhtml. It is not directly invalid,=20 according to the Atom format specifications. However, it is not very well= =20 supported either. I always contain the XHTML in paragraphs or other XHTML= =20 element; so it stays valid XML all the time. =E2=80=A6 This is a summary paragraph. =E2=80=A6 Is there a better way of doing this? =E2=80=94with =E2=80=98better=E2=80=99= , I am =E2=80=98better=20 supported and with a higher adoption rate=E2=80=99. My main concern is th= at some=20 feed readers may not be able to support my undocumented=20 implementation/interpretation. Anyone got any experiences in this field? What about the
or
elements from the HTML 5 (+XML)=20 working draft? They would both become much better containers than a=20 meaningless
if it is absolutely required to have one. --=20 Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Jan 30 16:54:20 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKsu-0000w3-Bl for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 16:54:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKst-0003Vo-Uz for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 16:54:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULgVRV033459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 14:42:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ULgV0G033458; Wed, 30 Jan 2008 14:42:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULgTva033452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 14:42:31 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.160] (helo=penny.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKKhQ-0000MC-Ki for atom-syntax@imc.org; Wed, 30 Jan 2008 22:42:28 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by penny.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKKhQ-0003ch-D7 for atom-syntax@imc.org; Wed, 30 Jan 2008 22:42:28 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: atom:id element vs. xml:id attribute Date: Wed, 30 Jan 2008 22:40:53 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200801302240.53559.aleksandersen+atomlist@runbox.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0ULgVvZ033453 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0ULgVRV033459 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi emailing list, (message contains Unicode characters) =20 Why does Atom use a special id element for identification instead of=20 relying on the xml:id attribute? Currently, I apply an identical value to= =20 both. urn:uuid:1 urn:uuid:2 The xml:id attribute makes parsing easier in a lot of environments=E2=80=94 especially in PHP 5 DOM XML=E2=80=94, but since the Atom format requires = an id=20 element; I have to include that as well. What decision lead to the=20 inclusion of the required atom:id element instead of the xml:id? Is there= =20 a point I am missing somewhere? xml:id is perfectly capable of performing the task of atom:id. I cannot=20 see why there would be any need for any special id element in any XML=20 format when we have got xml:id. --=20 Daniel Aleksandersen From quero@aliveinchristministries.com Wed Jan 30 17:21:50 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKLJW-00012E-F7 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 17:21:50 -0500 Received: from [189.71.67.87] (helo=18971070055.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKLJV-0003l7-Nj for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 17:21:50 -0500 Message-ID: <000901c8638e$7df3ba90$374647bd@homepc> From: "Bence Brewton" To: atompub-archive@lists.ietf.org Subject: Love her the right way : by adding inches to your manhood where it matters Date: Wed, 30 Jan 2008 19:21:42 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C86375.58A68290" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----------=_NextPart_000_0005_01C86375.58A68290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It used to be the only way she could come was if I went down on her. = Thanks to my new 9 inch tool, she now comes everytime we make love ----------=_NextPart_000_0005_01C86375.58A68290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It used to be the only way she = could come was=20 if I went down on her. Thanks to my new 9 inch tool, she now comes = everytime we=20 make love ----------=_NextPart_000_0005_01C86375.58A68290-- From owner-atom-syntax@mail.imc.org Wed Jan 30 17:31:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKLSS-0005l6-Qe for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 17:31:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKLSS-00042r-AY for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 17:31:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UMGBJg035983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 15:16:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UMGBeU035982; Wed, 30 Jan 2008 15:16:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UMG96J035973 for ; Wed, 30 Jan 2008 15:16:10 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id r21so406579wxc.28 for ; Wed, 30 Jan 2008 14:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=E4wKV01DB7wGp8WGgQ5FWQi/Bc3hq5fkrZBF9FYU9PQ=; b=QMTy3Iu3j9lOA9fBE6fqJBrsVNGtUakO9+cCyckgw42TJoi/q/Y0RdjYyCNuUEdniuukKoDlN+A7WDVXeys5BaN7sGhwwL1p/1DYqRL6/V3bd9FjQLzWfUDur+mhNWJGQmBFpHEN49rdYs7gWPKm3l+PIqa9zC6vSUbM4usPEXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=GB31I29o8gcssr0mIxfcBm885brrYTL/Eix9LHSNxpiNfdv+xGzGFBGtv6I1HTHcrevrwGrqwgjs09QhVB7Tz7UREf8hG4jWf9u7k6EFt/N3v8SCDLnkLBgE195L4bFAZQruT5Si2F8luyr07G445/rn+hNzsolJRg+pDfcB9ws= Received: by 10.142.162.5 with SMTP id k5mr749040wfe.171.1201731368250; Wed, 30 Jan 2008 14:16:08 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id h2sm2398187rnb.16.2008.01.30.14.16.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Jan 2008 14:16:07 -0800 (PST) Message-ID: <47A0F724.8090902@gmail.com> Date: Wed, 30 Jan 2008 14:16:04 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Daniel Aleksandersen CC: Atom emailing list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801302231.09548.aleksandersen+atomlist@runbox.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0UMGBJg035983 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Daniel Aleksandersen wrote: > Hi emailing list, (message contains Unicode characters) >=20 > I am curious about the status of the required
container when=20 > including xhtml in text constructs. With it be changed to become option= al=20 > instead? The below example never made much sense to me. >=20 No. it is required. > > =E2=80=A6 > > > This is a summary paragraph. > > > =E2=80=A6 > >=20 > Instead I am currently using a =E2=80=98hack=E2=80=99 which involves de= claring the type as=20 > application/xhtml+xml instead of xhtml. It is not directly invalid,=20 > according to the Atom format specifications. However, it is not very we= ll=20 > supported either. I always contain the XHTML in paragraphs or other XHT= ML=20 > element; so it stays valid XML all the time. >=20 > > =E2=80=A6 > > This is a summary paragraph. > > =E2=80=A6 > >=20 Don't do this. It's not valid either way. When=20 type=3D"application/xhtml+xml", the content is expected to be processable= =20 as a complete XHTML document, which obviously is not the case. Hacks=20 like this are most likely just to lead to interoperability problems later. > Is there a better way of doing this? =E2=80=94with =E2=80=98better=E2=80= =99, I am =E2=80=98better=20 > supported and with a higher adoption rate=E2=80=99. My main concern is = that some=20 > feed readers may not be able to support my undocumented=20 > implementation/interpretation. Anyone got any experiences in this field= ? >=20 The best approach is to stick to the standard and to not try to work=20 around it. - James > What about the
or
elements from the HTML 5 (+XML)=20 > working draft? They would both become much better containers than a=20 > meaningless
if it is absolutely required to have one. From owner-atom-syntax@mail.imc.org Wed Jan 30 17:45:43 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKLgd-0005Ct-Gb for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 17:45:43 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKLgd-0004Nt-2W for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 17:45:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UMWP9S037092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 15:32:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UMWPT4037091; Wed, 30 Jan 2008 15:32:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UMWMvK037083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 15:32:24 -0700 (MST) (envelope-from ga-atom-syntax@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JKLTa-00052y-R4 for atom-syntax@imc.org; Wed, 30 Jan 2008 22:32:15 +0000 Received: from ip68-101-220-172.sd.sd.cox.net ([68.101.220.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 22:32:14 +0000 Received: from hober0 by ip68-101-220-172.sd.sd.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 22:32:14 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: "Edward O'Connor" Subject: Re: Status of the wrapper Date: Wed, 30 Jan 2008 14:32:06 -0800 Organization: Church of Emacs Lines: 39 Message-ID: References: <200801302231.09548.aleksandersen+atomlist@runbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-101-220-172.sd.sd.cox.net Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEX47PoBAAegiLwiH1N IQYI0M4iMeKYBAAYGBBGqm9JF4g0mAAACYElEQVR4nGWTsY/aMBTGLXoLo8WQjNVrFJXxzviUbig JEcy5SNft5LhRGT3RNecUuRuiCMn/bZ+dhHDqJ2SZ7+f3nt/DEMOcqv9E9AdQTsD7fPw6hRIz+iw xxuhbMBn3SUtRofk95CTa9D49UIWiRvt4TnTiNmUbHIIDykUxdwm8lTvQUmergwoCpXR/qwojXqk 7jTEK1xANXhKOgD8eRmHggrt2CNKKtfcAU3EHkCbB5OJn4Ws40Prco6jhAyiDoSyeTrAb1gNe+dI eKNVlpvXNE5+pT6HUIjEi24a8B6XvjSrd0rCon5vCDwX7eA2wvV9bqrPWdCAFZBtfA0tQRWmRsE6 uZCMA6qYHbRDg6I5RlxVSFNCISG56QB3oIBNSRKL+JuLMg9LZlGqIUhCFlH9m8FN74GxFQwEFxKm crWYQJQ680v43TSEGEDArAWLJPVAObN8BHDghhrwcI1RYH2GSLMfiKnzWd6DGx4DvwNc41mIC0QQ WqzgXH0HV+kvVoohvIB5AaHRSyCZHyzawtOd4SBUyXR9lxOb2RB7Sz4T0AB8zY/smvWzRIrN0OQL GcsbW8zf7dY1gfsIlZm66JUsdOK3ljjjNCbnoHuxq9jQnb+TkAa6XY0XyJmf7C1uRwfbk4b0m1tr 8+zljb+ROD0+xA9f4umHP9+CTAAesjfGPWNyBvzCAc5ax/I40CFJPvkQrC/vRP+NsiC58LpGKfWH 7Ppy/JMY8ObK0AJfTRUDTz5eQxHS2VxPlG1697N0ee4qSbjeQ64bjc94Nhex1b+2N5Hn1MoJJwlp pf1Rr7/8DXitGHanPc2gAAAAASUVORK5CYII= X-Attribution: Ted Jabber-ID: hober0@gmail.com User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) Cancel-Lock: sha1:7I6rUZc482US0PV9IiJDiG32sow= Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0UMWP9S037092 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi Daniel, > I am curious about the status of the required
container when > including xhtml in text constructs. Wi[ll] it be changed to become > optional instead? There's no ongoing effort to revise the Atom syntax format, so assume this
will be required in the forseeable future. > Instead I am currently using a =E2=80=98hack=E2=80=99 which involves de= claring the > type as application/xhtml+xml instead of xhtml. Note that Atom's special-cased @type=3D"html" and @type=3D"xhtml" are explicitly for HTML *fragments*; if you use @type=3D"application/xhtml+xml", it's reasonable for an Atom processor to expect *an entire XHTML document*, element and all, inside your text construct. > Is there a better way of doing this? [...] My main concern is that > some feed readers may not be able to support my undocumented > implementation/interpretation. It's probably not a bad idea to use the HTML namespace as the default within your text construct, like so:

This is a summary paragraph.

--=20 Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From owner-atom-syntax@mail.imc.org Wed Jan 30 18:44:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMbI-0000MX-92 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 18:44:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMbG-0005ZQ-Me for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 18:44:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNUiXS041573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 16:30:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UNUivJ041572; Wed, 30 Jan 2008 16:30:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNUh5h041566 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 30 Jan 2008 16:30:44 -0700 (MST) (envelope-from Joe.Cheng@microsoft.com) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 30 Jan 2008 15:30:42 -0800 Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.158]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Wed, 30 Jan 2008 15:30:36 -0800 From: Joe Cheng To: Daniel Aleksandersen , Atom emailing list Date: Wed, 30 Jan 2008 15:30:36 -0800 Subject: RE: atom:id element vs. xml:id attribute Thread-Topic: atom:id element vs. xml:id attribute Thread-Index: Achji1aLrH9wWEw9RnWDt/hf6RrkeAAC8Evw Message-ID: References: <200801302240.53559.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801302240.53559.aleksandersen+atomlist@runbox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id m0UNUi5g041567 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0UNUiXS041573 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 From http://www.w3.org/TR/xml-id/ """An xml:id processor must assure that the following constraints hold for all xml:id attributes: The normalized value of the attribute is an NCName according to the Namespaces in XML Recommendation which has the same version as the document in which this attribute occurs (NCName for XML 1.0, or NCName for XML 1.1).""" Doesn't this mean you can't use a URI as an ID? -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.o= rg] On Behalf Of Daniel Aleksandersen Sent: Wednesday, January 30, 2008 1:41 PM To: Atom emailing list Subject: atom:id element vs. xml:id attribute Hi emailing list, (message contains Unicode characters) Why does Atom use a special id element for identification instead of relying on the xml:id attribute? Currently, I apply an identical value to both. urn:uuid:1 urn:uuid:2 The xml:id attribute makes parsing easier in a lot of environments=E2=80=94 especially in PHP 5 DOM XML=E2=80=94, but since the Atom format requires = an id element; I have to include that as well. What decision lead to the inclusion of the required atom:id element instead of the xml:id? Is there a point I am missing somewhere? xml:id is perfectly capable of performing the task of atom:id. I cannot see why there would be any need for any special id element in any XML format when we have got xml:id. -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Jan 30 18:52:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMj3-00087V-FE for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 18:52:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMj2-0005qo-Vw for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 18:52:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNbUi0041948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 16:37:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UNbUGw041947; Wed, 30 Jan 2008 16:37:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNbS86041939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 16:37:30 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.160] (helo=penny.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKMUh-0006xt-KV; Thu, 31 Jan 2008 00:37:27 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by penny.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKMUd-0004pN-RQ; Thu, 31 Jan 2008 00:37:26 +0100 From: Daniel Aleksandersen To: Joe Cheng Subject: Re: atom:id element vs. xml:id attribute Date: Thu, 31 Jan 2008 00:35:39 +0100 User-Agent: KMail/1.9.5 References: <200801302240.53559.aleksandersen+atomlist@runbox.com> In-Reply-To: Cc: Atom emailing list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200801310035.39162.aleksandersen+atomlist@runbox.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0UNbU85041942 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0UNbUi0041948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On 2008-01-31 00:30, Joe wrote: > From http://www.w3.org/TR/xml-id/ > > """An xml:id processor must assure that the following constraints > hold for all xml:id attributes: > > The normalized value of the attribute is an NCName according > to the Namespaces in XML Recommendation which has the same > version as the document in which this attribute occurs (NCName > for XML 1.0, or NCName for XML 1.1).""" > > Doesn't this mean you can't use a URI as an ID? No, not from what I can tell. An ID must be unique within the document.=20 Regarding naming it must start with a letter or an underscore. Other than= =20 that, there is nothing indicating that it cannot be an IRI. > -----Original Message----- > From: owner-atom-syntax@mail.imc.org > [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Daniel > Aleksandersen Sent: Wednesday, January 30, 2008 1:41 PM > To: Atom emailing list > Subject: atom:id element vs. xml:id attribute > > > Hi emailing list, (message contains Unicode characters) > > Why does Atom use a special id element for identification instead of > relying on the xml:id attribute? Currently, I apply an identical value > to both. > > > urn:uuid:1 > > urn:uuid:2 > > > > The xml:id attribute makes parsing easier in a lot of environments=E2=80= =94 > especially in PHP 5 DOM XML=E2=80=94, but since the Atom format require= s an id > element; I have to include that as well. What decision lead to the > inclusion of the required atom:id element instead of the xml:id? Is > there a point I am missing somewhere? > > xml:id is perfectly capable of performing the task of atom:id. I cannot > see why there would be any need for any special id element in any XML > format when we have got xml:id. -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Jan 30 18:57:05 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMnh-0006yY-EN for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 18:57:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMnh-00066H-28 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 18:57:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNijHQ042242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 16:44:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UNiiCE042241; Wed, 30 Jan 2008 16:44:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNih3j042234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 30 Jan 2008 16:44:44 -0700 (MST) (envelope-from Joe.Cheng@microsoft.com) Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 30 Jan 2008 15:44:43 -0800 Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.158]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed, 30 Jan 2008 15:44:43 -0800 From: Joe Cheng To: Daniel Aleksandersen CC: Atom emailing list Date: Wed, 30 Jan 2008 15:44:44 -0800 Subject: RE: atom:id element vs. xml:id attribute Thread-Topic: atom:id element vs. xml:id attribute Thread-Index: AchjmRVN4Fx+2TEQQqypBGS+LusmZwAAOq3Q Message-ID: References: <200801302240.53559.aleksandersen+atomlist@runbox.com> <200801310035.39162.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801310035.39162.aleksandersen+atomlist@runbox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id m0UNii3i042236 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed > Other than that, there is nothing indicating that it > cannot be an IRI. If it has to be NCName then it can't contain a colon. Am I wrong in concluding that it has to be NCName? From owner-atom-syntax@mail.imc.org Wed Jan 30 19:01:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMsO-0003VH-Va for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:01:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMsO-0006Br-JG for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:01:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNnRjQ042571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 16:49:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UNnRvT042569; Wed, 30 Jan 2008 16:49:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNnPRG042560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 16:49:27 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKMgH-0003jo-0N; Thu, 31 Jan 2008 00:49:25 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKMgE-000898-Vu; Thu, 31 Jan 2008 00:49:24 +0100 From: Daniel Aleksandersen To: Joe Cheng Subject: Re: atom:id element vs. xml:id attribute Date: Thu, 31 Jan 2008 00:47:41 +0100 User-Agent: KMail/1.9.5 References: <200801302240.53559.aleksandersen+atomlist@runbox.com> <200801310035.39162.aleksandersen+atomlist@runbox.com> In-Reply-To: Cc: Atom emaling list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801310047.41262.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On 2008-01-31 00:44, you wrote: > > Other than that, there is nothing indicating that it > > cannot be an IRI. > > If it has to be NCName then it can't contain a colon. Am > I wrong in concluding that it has to be NCName? Actually, you are quite right. It must be a NCName, and that does leave out colon. I have never read that part of the specification that carefully. Comming to think about it, I knew it could not contain a colon from my previous works with CSS and ID attributes in XHTML. But my question on why the atom:id element is being used instead of the xml:id attribute still stands. -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Jan 30 19:08:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMz0-0004Zz-07 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:08:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMyy-0006HS-QK for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:08:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNtdma042871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 16:55:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UNtdTk042870; Wed, 30 Jan 2008 16:55:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UNtbAX042863 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 16:55:38 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKMmG-000717-KW; Thu, 31 Jan 2008 00:55:36 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKMmG-0006AG-FJ; Thu, 31 Jan 2008 00:55:36 +0100 From: Daniel Aleksandersen To: Edward =?utf-8?q?O=E2=80=99Connor?= Subject: Re: Status of the wrapper Date: Thu, 31 Jan 2008 00:54:01 +0100 User-Agent: KMail/1.9.5 References: <200801302231.09548.aleksandersen+atomlist@runbox.com> In-Reply-To: Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200801310054.01673.aleksandersen+atomlist@runbox.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0UNtdAW042865 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0UNtdma042871 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On 2008-01-30 23:32, you wrote: > Hi Daniel, > > > I am curious about the status of the required
container when > > including xhtml in text constructs. Wi[ll] it be changed to become > > optional instead? > > There's no ongoing effort to revise the Atom syntax format, so assume > this
will be required in the forseeable future. That is a shame. > > Instead I am currently using a =E2=80=98hack=E2=80=99 which involves = declaring the > > type as application/xhtml+xml instead of xhtml. > > Note that Atom's special-cased @type=3D"html" and @type=3D"xhtml" are > explicitly for HTML *fragments*; if you use > @type=3D"application/xhtml+xml", it's reasonable for an Atom processor = to > expect *an entire XHTML document*, element and all, inside your > text construct. Then maybe I should include an entire XHTML document structure. That woul= d=20 make more sense than including XHTML fragments contained in a div=20 element. (That unnecessary div really bugs me, for some reason.) > > Is there a better way of doing this? [...] My main concern is that > > some feed readers may not be able to support my undocumented > > implementation/interpretation. > > It's probably not a bad idea to use the HTML namespace as the default > within your text construct, like so: > > >
>

> This is a summary paragraph. >

>
> Are there any downsides to defining the namespace in the atom:feed elemen= t=20 instead of repeating it troughout the document? --=20 Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Jan 30 19:18:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKN8L-0001IZ-Pu for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:18:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKN8L-0006Rr-Ay for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:18:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V01mGA043196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 17:01:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V01m3K043195; Wed, 30 Jan 2008 17:01:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V01l3P043189 for ; Wed, 30 Jan 2008 17:01:47 -0700 (MST) (envelope-from david@fastolfe.net) Received: by wr-out-0506.google.com with SMTP id c53so502930wra.22 for ; Wed, 30 Jan 2008 16:01:47 -0800 (PST) Received: by 10.142.157.15 with SMTP id f15mr850374wfe.16.1201737706292; Wed, 30 Jan 2008 16:01:46 -0800 (PST) Received: by 10.142.144.7 with HTTP; Wed, 30 Jan 2008 16:01:46 -0800 (PST) Message-ID: <7fe006b30801301601i4350f69aq3ebeb061b07affc6@mail.gmail.com> Date: Wed, 30 Jan 2008 16:01:46 -0800 From: "David Nesting" To: "Daniel Aleksandersen" Subject: Re: Status of the wrapper Cc: "Atom emailing list" In-Reply-To: <200801302231.09548.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22511_7139649.1201737706318" References: <200801302231.09548.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_Part_22511_7139649.1201737706318 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/30/08, Daniel Aleksandersen wrote: > > I am curious about the status of the required
container when > including xhtml in text constructs. With it be changed to become optional > instead? The below example never made much sense to me. > Bear in mind that the div element used within "xhtml" content should not actually appear within the resulting content. When an Atom application parses this feed, it's expected to drop the div element and only use the content within it. If your intent is to include only an XHTML paragraph element, the first example is actually correct. The div element shouldn't persist. David ------=_Part_22511_7139649.1201737706318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 1/30/08, Daniel Aleksandersen <aleksandersen+atomlist@runbox.com> wrote:
I am curious about the status of the required <div> container when
including xhtml in text constructs. With it be changed to become optional
instead? The below example never made much sense to me.

Bear in mind that the div element used within "xhtml" content should not actually appear within the resulting content.  When an Atom application parses this feed, it's expected to drop the div element and only use the content within it.  If your intent is to include only an XHTML paragraph element, the first example is actually correct.  The div element shouldn't persist.

David
------=_Part_22511_7139649.1201737706318-- From owner-atom-syntax@mail.imc.org Wed Jan 30 19:21:03 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNAt-0001rY-Td for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:21:03 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKNAt-0006TS-G6 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:21:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0AffI043725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 17:10:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V0Af7Y043724; Wed, 30 Jan 2008 17:10:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0AdtR043709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 17:10:40 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKN0j-0001NO-Q4; Thu, 31 Jan 2008 01:10:33 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKN0i-0004Ys-MH; Thu, 31 Jan 2008 01:10:33 +0100 From: Daniel Aleksandersen To: David Nesting Subject: Re: Status of the wrapper Date: Thu, 31 Jan 2008 01:08:56 +0100 User-Agent: KMail/1.9.5 References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <7fe006b30801301601i4350f69aq3ebeb061b07affc6@mail.gmail.com> In-Reply-To: <7fe006b30801301601i4350f69aq3ebeb061b07affc6@mail.gmail.com> Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801310108.56551.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On 2008-01-31 01:01, you wrote: > On 1/30/08, Daniel Aleksandersen wrote: > > I am curious about the status of the required
container when > > including xhtml in text constructs. With it be changed to become > > optional instead? The below example never made much sense to me. > > Bear in mind that the div element used within "xhtml" content should > not actually appear within the resulting content. When an Atom > application parses this feed, it's expected to drop the div element and > only use the content within it. If your intent is to include only an > XHTML paragraph element, the first example is actually correct. The > div element shouldn't persist. Then what is wrong with the below? Is this such a bold thing to do? I am trying to understand why XHTML fragments must be contained within two containers (the atom:summary AND the xht:div elements). -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Wed Jan 30 19:42:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNV9-0002PP-Vm for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:41:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKNV9-0007Dk-JV for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:41:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0VKMH045344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 17:31:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V0VKOX045343; Wed, 30 Jan 2008 17:31:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0VJHB045337 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 30 Jan 2008 17:31:19 -0700 (MST) (envelope-from Joe.Cheng@microsoft.com) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 30 Jan 2008 16:31:18 -0800 Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.158]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Wed, 30 Jan 2008 16:31:18 -0800 From: Joe Cheng To: Daniel Aleksandersen CC: Atom emaling list Date: Wed, 30 Jan 2008 16:31:17 -0800 Subject: RE: atom:id element vs. xml:id attribute Thread-Topic: atom:id element vs. xml:id attribute Thread-Index: AchjmsI5GRBlVieOTeCM5dsRAu5vEQABYWzQ Message-ID: References: <200801302240.53559.aleksandersen+atomlist@runbox.com> <200801310035.39162.aleksandersen+atomlist@runbox.com> <200801310047.41262.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801310047.41262.aleksandersen+atomlist@runbox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id m0V0VJHA045338 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed > But my question on why the atom:id element is being used > instead of the xml:id attribute still stands. But... atom:id has to contain an IRI. http://tools.ietf.org/html/rfc4287#section-4.2.6 From owner-atom-syntax@mail.imc.org Wed Jan 30 19:44:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNXP-00061X-QX for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:44:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKNXP-0007FO-61 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:44:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0XwQT045523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 17:33:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V0XwbQ045522; Wed, 30 Jan 2008 17:33:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0XtWR045515 for ; Wed, 30 Jan 2008 17:33:57 -0700 (MST) (envelope-from david@fastolfe.net) Received: by wx-out-0506.google.com with SMTP id r21so458056wxc.28 for ; Wed, 30 Jan 2008 16:33:54 -0800 (PST) Received: by 10.142.225.11 with SMTP id x11mr844812wfg.115.1201739633714; Wed, 30 Jan 2008 16:33:53 -0800 (PST) Received: by 10.142.144.7 with HTTP; Wed, 30 Jan 2008 16:33:53 -0800 (PST) Message-ID: <7fe006b30801301633q27d4f9dqf6e7a1d64a780300@mail.gmail.com> Date: Wed, 30 Jan 2008 16:33:53 -0800 From: "David Nesting" To: "Daniel Aleksandersen" Subject: Re: Status of the wrapper Cc: "Atom emailing list" In-Reply-To: <200801310108.56551.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22673_4241660.1201739633722" References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <7fe006b30801301601i4350f69aq3ebeb061b07affc6@mail.gmail.com> <200801310108.56551.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ------=_Part_22673_4241660.1201739633722 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/30/08, Daniel Aleksandersen wrote: > > Then what is wrong with the below? > > > Is this such a bold thing to do? > > This has been discussed on the list a few times. If you haven't already, consider going through the archives if you're interested in seeing the rationale behind this decision. The chief benefit in my eyes is allowing for the ability to change the default namespace to improve the readability of your content's markup. It also underscores the fact that you're working with an XHTML document fragment, not an entire document. You should only feel comfortable putting content within the div element that you'd be comfortable putting within a div element inside of a real XHTML document. But does any of this really matter at this point? Even if there were good reasons to change this aspect of the standard, you'd introduce interoperability problems, because Atom implementations expect a div element to be there. If you make it optional, how would you unambiguously use a div element as a container for your content without some implementations trying to strip it out? You'd have to create some new mechanism to make the decision to strip it out explicit (and probably the default behavior), which means you're trading one oddity (div) for another (@strip-first-element="false").. David ------=_Part_22673_4241660.1201739633722 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 1/30/08, Daniel Aleksandersen <aleksandersen+atomlist@runbox.com> wrote:
Then what is wrong with the below?

<summary type="xhtml" xmlns:xht="http://www.w3.org/1999/xhtml">
  <xht:p>Is this such a <xht:strong>bold</xht:strong> thing to do?</xht:p>
</summary>

This has been discussed on the list a few times.  If you haven't already, consider going through the archives if you're interested in seeing the rationale behind this decision.  The chief benefit in my eyes is allowing for the ability to change the default namespace to improve the readability of your content's markup.  It also underscores the fact that you're working with an XHTML document fragment, not an entire document.  You should only feel comfortable putting content within the div element that you'd be comfortable putting within a div element inside of a real XHTML document.

But does any of this really matter at this point?  Even if there were good reasons to change this aspect of the standard, you'd introduce interoperability problems, because Atom implementations expect a div element to be there.  If you make it optional, how would you unambiguously use a div element as a container for your content without some implementations trying to strip it out?  You'd have to create some new mechanism to make the decision to strip it out explicit (and probably the default behavior), which means you're trading one oddity (div) for another (@strip-first-element="false")..

David
------=_Part_22673_4241660.1201739633722-- From owner-atom-syntax@mail.imc.org Wed Jan 30 19:50:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNdB-0000HF-RL for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:50:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKNdB-0007LW-Ef for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:50:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0cF3B045764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 17:38:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V0cFvW045763; Wed, 30 Jan 2008 17:38:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0cEco045756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 30 Jan 2008 17:38:15 -0700 (MST) (envelope-from Joe.Cheng@microsoft.com) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 30 Jan 2008 16:38:14 -0800 Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.158]) by tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Wed, 30 Jan 2008 16:38:13 -0800 From: Joe Cheng To: Daniel Aleksandersen , =?utf-8?B?RWR3YXJkIE/igJlDb25ub3I=?= CC: Atom emailing list Date: Wed, 30 Jan 2008 16:38:12 -0800 Subject: RE: Status of the wrapper Thread-Topic: Status of the wrapper Thread-Index: AchjnY8+DnGK2G3xTgShbeJlTSLnJQAAz0dA Message-ID: References: <200801302231.09548.aleksandersen+atomlist@runbox.com> <200801310054.01673.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801310054.01673.aleksandersen+atomlist@runbox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id m0V0cFcn045758 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > Then maybe I should include an entire XHTML document structure. > That would make more sense than including XHTML fragments > contained in a div element. (That unnecessary div really bugs > me, for some reason.) The question is, does it bug you enough to sacrifice interop with pretty much any AtomPub client or server out there? Cause we're all expecting type="xhtml" and the div; I don't think anyone is going to do anything nearly as sensible with application/xhtml+xml as they would with type="xhtml". There are a few little details about the AtomPub spec that bug me too, but don't forget that interop is the main reason for all this stuff. Interop first, reuse second, personal hang-ups about inelegant packaging a (very) distant third... :) From owner-atom-syntax@mail.imc.org Wed Jan 30 19:52:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNfY-0004pa-QZ for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:52:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKNfY-0007Os-A4 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 19:52:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0eshl045908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 17:40:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V0eshN045907; Wed, 30 Jan 2008 17:40:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V0eqak045901 for ; Wed, 30 Jan 2008 17:40:53 -0700 (MST) (envelope-from david@fastolfe.net) Received: by wr-out-0506.google.com with SMTP id c53so515945wra.22 for ; Wed, 30 Jan 2008 16:40:52 -0800 (PST) Received: by 10.142.155.4 with SMTP id c4mr833421wfe.208.1201740051516; Wed, 30 Jan 2008 16:40:51 -0800 (PST) Received: by 10.142.144.7 with HTTP; Wed, 30 Jan 2008 16:40:51 -0800 (PST) Message-ID: <7fe006b30801301640o7eb756cer4263dc3a51225438@mail.gmail.com> Date: Wed, 30 Jan 2008 16:40:51 -0800 From: "David Nesting" To: "Daniel Aleksandersen" Subject: Re: atom:id element vs. xml:id attribute Cc: "Joe Cheng" , "Atom emaling list" In-Reply-To: <200801310047.41262.aleksandersen+atomlist@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22699_19315164.1201740051516" References: <200801302240.53559.aleksandersen+atomlist@runbox.com> <200801310035.39162.aleksandersen+atomlist@runbox.com> <200801310047.41262.aleksandersen+atomlist@runbox.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_Part_22699_19315164.1201740051516 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/30/08, Daniel Aleksandersen wrote: > > But my question on why the atom:id element is being used instead of the > xml:id attribute still stands. > It is desirable for the identifier to be an IRI. You can ensure global uniqueness this way and your identifiers can be structured, readable, and possibly participate in existing identifiers used on your web site (such as the entry's permanent URL). While you might be able to adopt additional constraints to apply to xml:id attributes to achieve the same goals, this would be awkward given xml:id's restrictions, potentially confusing since you're effectively overloading the semantics of xml:id, and potentially painful if someone attempts to create or embed an xml:id obeying XML's rules but violating Atom's rules. Not all XML within an Atom document will be Atom. David ------=_Part_22699_19315164.1201740051516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 1/30/08, Daniel Aleksandersen <aleksandersen+atomlist@runbox.com> wrote:
But my question on why the atom:id element is being used instead of the
xml:id attribute still stands.

It is desirable for the identifier to be an IRI.  You can ensure global uniqueness this way and your identifiers can be structured, readable, and possibly participate in existing identifiers used on your web site (such as the entry's permanent URL).  While you might be able to adopt additional constraints to apply to xml:id attributes to achieve the same goals, this would be awkward given xml:id's restrictions, potentially confusing since you're effectively overloading the semantics of xml:id, and potentially painful if someone attempts to create or embed an xml:id obeying XML's rules but violating Atom's rules.  Not all XML within an Atom document will be Atom.

David
------=_Part_22699_19315164.1201740051516-- From owner-atom-syntax@mail.imc.org Wed Jan 30 20:49:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKOYe-0004De-Om for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 20:49:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKOYe-0000KH-7M for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 20:49:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V1cJ0e049900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 18:38:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V1cJGQ049899; Wed, 30 Jan 2008 18:38:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V1cIMc049893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2008 18:38:19 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.170.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 68BA9D051E for ; Wed, 30 Jan 2008 20:38:16 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" Subject: RE: atom:id element vs. xml:id attribute Date: Wed, 30 Jan 2008 17:38:17 -0800 Message-ID: <003501c863a9$f4bd03f0$0501a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchjmwCHge1FCwEPR/WzYbIX+SQHjAAC7W5QAADOApA= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0V1cJMb049894 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Daniel wrote: > But my question on why the atom:id element is being used instead of > the xml:id attribute still stands. * xml:id is only expected to be locally unique. The intention of atom:id is to be globally unique. If you think about the aggregation and syndication model of Atom, then the desire to have globally-unique identifiers becomes clear. The de-facto standard for globally unique identifiers is to use IRIs or UUIDs, and so I guess IRIs were chosen as they are more general (UUIDs can be represented with IRIs). Since xml:id can't hold an IRI or even a URI, xml:id could not be used. (Unfortunately, because there is no way to ensure that atom:ids are globally unique, applications generally have to treat them as though they are locally unique, unless they do a lot of extra work to verify the origin of an entry.) * If you adhere to the xml:id recommendation, then the value of every xml:id attribute in a document has to be unique within that document. That requirement makes it difficult to mix fragments from different documents together into the same document. Because Atom doesn't require Atom processors to adhere to the xml:id recommendation, this issue doesn't arise with Atom feeds. * If you use xml:id as an XML ID in a feed document, then you can construct a URI that uses a fragment identifier to refer to the entry within the document. However, this is at odds with the paging and archiving model that is used by Atom. An entry might be at http://example.org/latest.atom#entry-id today, and http://example.org/january-2008.atom#entry-id next week. You can't use redirects based on fragment identifiers. And in fact, http://example.org/latest.atom#entry-id might point to a completely different entry (different atom:id) next week than it does today, and still be compliant with the xml:id recommendation (another motivation for #1 above). By not having an XML ID attributes in Atom, the whole issue of referring to entries in a feed using fragment identifiers is avoided. If you really want to refer to an entry with a particular ID that can be found at a particular (paged) collection, then you need to reference it using some not-yet-invented "atom:" IRI scheme (e.g. atom:http://exampel.org/blog.feed:http://example.org/blog/maybe-you-should-use-this-IRI-instead.entry). * The xml:id specification conflicts with the XML 1.0 recommendation. These conflicts have made xml:id very controversial and it seems nobody is really using it for anything. Effectively, it is DOA. - Brian From atompson@corusent.com Wed Jan 30 21:37:43 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKPJ9-00046W-FY for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 21:37:43 -0500 Received: from bb116-14-186-28.singnet.com.sg ([116.14.186.28] helo=bbcache-103.singnet.com.sg) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKPJ8-000296-GO for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 21:37:43 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 7966 by uid 137); Thu, 31 Jan 2008 10:37:51 -0800 Message-Id: <20080131023751.7968.qmail@bbcache-103.singnet.com.sg> To: Subject: January 76% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
From owner-atom-syntax@mail.imc.org Wed Jan 30 22:30:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKQ7y-000347-5o for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 22:30:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKQ7w-0001mh-K3 for atompub-archive@lists.ietf.org; Wed, 30 Jan 2008 22:30:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V3ICRD055596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 20:18:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V3ICaQ055595; Wed, 30 Jan 2008 20:18:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bay0-omc3-s38.bay0.hotmail.com (bay0-omc3-s38.bay0.hotmail.com [65.54.246.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V3IBST055589 for ; Wed, 30 Jan 2008 20:18:12 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.15]) by bay0-omc3-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jan 2008 19:18:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Jan 2008 19:18:10 -0800 Message-ID: Received: from 85.211.247.140 by BAY141-DAV5.phx.gbl with DAV; Thu, 31 Jan 2008 03:18:09 +0000 X-Originating-IP: [85.211.247.140] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom emailing list" References: <200801302231.09548.aleksandersen+atomlist@runbox.com> Subject: Re: Status of the wrapper Date: Thu, 31 Jan 2008 03:20:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 31 Jan 2008 03:18:10.0803 (UTC) FILETIME=[E853CC30:01C863B7] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0V3ICRD055596 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Daniel Aleksandersen wrote: > > =E2=80=A6 > > This is a summary paragraph. > > =E2=80=A6 > > > Is there a better way of doing this? =E2=80=94with =E2=80=98better=E2=80= =99, I am =E2=80=98better > supported and with a higher adoption rate=E2=80=99. My main concern is = that some > feed readers may not be able to support my undocumented > implementation/interpretation. Anyone got any experiences in this field= ? First off, summary elements can't have a type of "application/xhtml+xml" = -=20 MIME media types are only permitted on content elements. However, if you're happy to use a content element, then=20 "application/xhtml+xml" works almost as well as "xhtml" in my experience.= =20 The catch is that you must use an xhtml fragment. If you include a full=20 xhtml document (as recommended by the spec), your results will tend to be= a=20 lot worse. Whatever you do, though, don't use namespace prefixes - aggregators don't= =20 deal at all well with that. And in case it's not obvious, your best bet is actually to avoid xhtml=20 altogether and use escaped html - but I suspect you won't want to do that. Regards James From owner-atom-syntax@mail.imc.org Thu Jan 31 00:04:49 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKRbV-0000nk-Lv for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 00:04:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKRbV-0002uu-8N for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 00:04:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V4plge061864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 21:51:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V4plDx061862; Wed, 30 Jan 2008 21:51:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m0V4pjet061834 for ; Wed, 30 Jan 2008 21:51:46 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904855330 for ; Thu, 31 Jan 2008 15:51:33 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 31 Jan 2008 15:51:37 +1100 Subject: Re: Status of the wrapper From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200801310054.01673.aleksandersen+atomlist@runbox.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0V4pket061854 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0V4plge061864 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On 31/1/08 10:54 AM, "Daniel Aleksandersen" wrote: >> >>
>>

>> This is a summary paragraph. >>

>>
>> >=20 > Are there any downsides to defining the namespace in the atom:feed elem= ent > instead of repeating it troughout the document? the downside is that you have to repeat the xht:ns prefix on all the chil= d elements: =8A =20 This is a summary paragraph. =20 =8A Any content not much more complicated than that very simple example and i= t would actually be more bytes than repeating the declaration inside each summary. That, plus the hassle of you adding the prefix, and the receiver removing the prefix .. much simpler all round to repeat the ns declaration on the
wrapper each time. e. From owner-atom-syntax@mail.imc.org Thu Jan 31 04:53:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKW76-0004Xw-9l for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 04:53:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKW74-0007GX-PY for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 04:53:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V9d16K081024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 02:39:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V9d1FS081023; Thu, 31 Jan 2008 02:39:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with SMTP id m0V9cxs1081016 for ; Thu, 31 Jan 2008 02:39:00 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 31 Jan 2008 09:38:57 -0000 Received: from p508F80F8.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.128.248] by mail.gmx.net (mp021) with SMTP; 31 Jan 2008 10:38:57 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX185YkRMhAk5SglID1QTYItrGVPVr75zKJBdIaP1bh mD1pgiQ1N4wTwT Message-ID: <47A1972F.7010705@gmx.de> Date: Thu, 31 Jan 2008 10:38:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: James Holderness CC: Atom emailing list Subject: Re: Status of the wrapper References: <200801302231.09548.aleksandersen+atomlist@runbox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 James Holderness wrote: > ... > Whatever you do, though, don't use namespace prefixes - aggregators > don't deal at all well with that. > ... I'd take that as a good reason to use them, unless interop with broken clients is really required. > ... BR, Julian From owner-atom-syntax@mail.imc.org Thu Jan 31 05:59:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKX8Y-0003JR-2S for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 05:59:18 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKX8X-0008Tm-JQ for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 05:59:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0VAjkPf086493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 03:45:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0VAjk8A086492; Thu, 31 Jan 2008 03:45:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0VAjiQb086480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 03:45:46 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKWvC-0001o2-Hp; Thu, 31 Jan 2008 11:45:30 +0100 Received: from [84.209.54.73] (helo=cm-84.209.54.73.getinternet.no) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKWvC-0006ES-6e; Thu, 31 Jan 2008 11:45:30 +0100 From: Daniel Aleksandersen To: Eric Scheid Subject: Re: Status of the wrapper Date: Thu, 31 Jan 2008 11:43:53 +0100 User-Agent: KMail/1.9.5 References: In-Reply-To: Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200801311143.54164.aleksandersen+atomlist@runbox.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m0VAjkQa086487 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0VAjkPf086493 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On 2008-01-31 05:51, you wrote: > On 31/1/08 10:54 AM, "Daniel Aleksandersen" > > wrote: > >> > >>
> >>

> >> This is a summary paragraph. > >>

> >>
> >> > > > > Are there any downsides to defining the namespace in the atom:feed > > element instead of repeating it troughout the document? > > the downside is that you have to repeat the xht:ns prefix on all the > child elements: > > > =C2=8A > > > This is a summary paragraph. > > > =C2=8A > > > Any content not much more complicated than that very simple example and > it would actually be more bytes than repeating the declaration inside > each summary. > > That, plus the hassle of you adding the prefix, and the receiver > removing the prefix .. much simpler all round to repeat the ns > declaration on the
wrapper each time. One can easily add and remove the prefixes using any XML parser. (Which i= s=20 required to work with Atom feeds anyways.) I m really left with no choice but to use both and
, and=20 with no predeclared namespace. I wonder why the specification even=20 mentions other approaches then. Regarding application/xhtml+xml in .=E2=80=A6 Must I include a f= ull=20 document type and all? Or is it only the full tree construct (from= =20 that element) that is required? I think I will stick with representing a simple text=E2=80=90type and a l= ink!! :-P --=20 Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Thu Jan 31 14:34:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKfAe-0000Zs-RR for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 14:34:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKfAe-00064G-C7 for atompub-archive@lists.ietf.org; Thu, 31 Jan 2008 14:34:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0VJJaEu032111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 12:19:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0VJJan1032110; Thu, 31 Jan 2008 12:19:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0VJJYGg032096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 12:19:35 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.138] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id m0VJJTsv020914; Thu, 31 Jan 2008 13:19:30 -0600 Message-ID: <47A22CF4.4070303@defuze.org> Date: Thu, 31 Jan 2008 20:17:56 +0000 From: Sylvain Hellegouarch User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Karl Dubost CC: James Holderness , Atom-Syntax Subject: Re: Atom feed design for a variety of media types References: <23fce8e60801140627s7a2372b8mcce924153f6e2904@mail.gmail.com> <23fce8e60801141543i3e55190dxc3fc3c125e3f07c5@mail.gmail.com> <478C44B7.3060908@gmail.com> <478DD7B3.8090705@defuze.org> <478E28EB.1070203@gmail.com> <405E5FF5-D645-4DB6-9106-4831229B833C@simplepie.org> <8A0286F4-1C56-4C07-A690-B5A017BFF71E@w3.org> <479B88CF.3070000@gmail.com> <479BBE7E.1020001@defuze.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id m0VJJaEu032111 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a It's an interesting resource for sure and even more the fact that it is=20 a W3C initiative however it appears after (quickly I admit) browsing=20 the WG pages that they don't recommend a set of standard metadata to use. This is a great directory of resources around media metadata nonetheless. - Sylvain Karl Dubost a =E9crit : > > Le 27 janv. 2008 =E0 08:13, Sylvain Hellegouarch a =E9crit : >> However if we decide to extend the atom vocabulary like Yahoo did=20 >> with Media-RSS, we ought to actually discuss first with the main=20 >> players in the field today (Apple, Microsoft, Xiph, EXIF, etc.) in=20 >> order to define the minimal relevant set of metadata for common media=20 >> formats. > > Just for information, there has been work done also by a [W3C=20 > incubator][1] group on [Multimedia Vocabularies][2]. It gives an=20 > overview of the existing formats and their associated metadata. It's=20 > quite cool. > > # 1. Introduction > > * 1.1 Declaration of Namespaces > * 1.2 Related Pages > > # 2. Types of Multimedia Metadata > # 3. Existing Multimedia Metadata Formats > > * 3.1 Multimedia Metadata Formats For Describing Still Images > * 3.2 Multimedia Metadata Formats For Describing Audio Content > * 3.3 Multimedia Metadata Formats For Describing Audio-Visual Conte= nt > * 3.4 Multimedia Metadata Formats For Describing Multimedia=20 > Presentations > * 3.5 Multimedia Metadata Formats For Describing Specific Domains=20 > Or Workflows > * 3.6 Other Multimedia Metadata Related Formats > > > > [1]: http://www.w3.org/2005/Incubator/ > [2]: http://www.w3.org/2005/Incubator/mmsem/XGR-vocabularies/ > > > > > > > --=20 > Karl Dubost - W3C > http://www.w3.org/QA/ > Be Strict To Be Cool > > > > > From owner-atom-syntax@mail.imc.org Thu Jan 31 16:51:48 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3157628C139 for ; Thu, 31 Jan 2008 16:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.968 X-Spam-Level: X-Spam-Status: No, score=0.968 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0K-qm5btP6J for ; Thu, 31 Jan 2008 16:51:47 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 254AF28C145 for ; Thu, 31 Jan 2008 16:51:09 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m110duVR059211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 17:39:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m110durl059210; Thu, 31 Jan 2008 17:39:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m110dsqS059188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 17:39:55 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKjwS-0005Q8-R9 for atom-syntax@imc.org; Fri, 01 Feb 2008 01:39:40 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKjwS-0001Zx-7Q for atom-syntax@imc.org; Fri, 01 Feb 2008 01:39:40 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: Long list of relations Date: Fri, 1 Feb 2008 01:37:59 +0100 User-Agent: KMail/1.9.5 Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802010138.00059.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m110dtqR059205 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi emailing list, (message contains Unicode characters) I am constructing a feed or recent published articles and a feed archive. Each atom:entry contains a lot of atom:links. I am going to set a title to them as well (the comments below) later too. What link relations ( http://www.iana.org/assignments/link-relations.html) are most appropriate for the various scenarios below? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Thu Jan 31 17:15:03 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EF63A67AE for ; Thu, 31 Jan 2008 17:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtsWE9UAEaKd for ; Thu, 31 Jan 2008 17:15:02 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6A35A3A67A2 for ; Thu, 31 Jan 2008 17:15:02 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1117Rws060890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 18:07:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1117RRi060889; Thu, 31 Jan 2008 18:07:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1117O0l060881 for ; Thu, 31 Jan 2008 18:07:26 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id a25so1058911pyi.11 for ; Thu, 31 Jan 2008 17:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=3MKZfE1BOxwJTorf0LpfxzdwJgz0bUURMU6Q/xJCLv8=; b=X85QzjqwdF6AslzKNeLTkUEM8CTSJhKNwrCtyrcKdunt5Sf9h3Fg+R5KkXlG+wfaWLjw47PpKneEt07hDTvHAyohSuh0nTLOcR6RCO2Eh4hsIZ10gWojYMYfgw5L4IqhK+DS7MSWswfbO2JtpnTfE0NzJT9sfjXMCYjH2+tLlyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=wQtyLix8FNtZ9AJ3t1Hs+FCMGDRjYdKsKYoDJA1VtTIPpONnxeyzYRFtFFvC52KNBnPCDFZM2cawXxD0udZKQBRpSqibq6gtvz6fizeSFrDBiRuMBK9+DodoznwK34F1/EX5neCL4cv/5HosFbFUX5b4e4e0+651/93JJ8RiMRs= Received: by 10.141.87.13 with SMTP id p13mr2034812rvl.62.1201828043024; Thu, 31 Jan 2008 17:07:23 -0800 (PST) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id a68sm5028815rnc.14.2008.01.31.17.07.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Jan 2008 17:07:22 -0800 (PST) Message-ID: <47A270C8.5040507@gmail.com> Date: Thu, 31 Jan 2008 17:07:20 -0800 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Daniel Aleksandersen CC: Atom emailing list Subject: Re: Long list of relations References: <200802010138.00059.aleksandersen+atomlist@runbox.com> In-Reply-To: <200802010138.00059.aleksandersen+atomlist@runbox.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > Hi emailing list, (message contains Unicode characters) > [snip] > type="application/xhtml+xml" rel="alternate via" /> atom:link rel attributes are limited to a single value. You cannot specify multiple values per link. - James From owner-atom-syntax@mail.imc.org Thu Jan 31 17:58:11 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB20E28C28E for ; Thu, 31 Jan 2008 17:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.061 X-Spam-Level: * X-Spam-Status: No, score=1.061 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+4j0Tyh1CG5 for ; Thu, 31 Jan 2008 17:58:11 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 325B928C0D7 for ; Thu, 31 Jan 2008 17:57:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m111no5d063944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 18:49:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m111noeq063943; Thu, 31 Jan 2008 18:49:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m111nmir063936 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 18:49:49 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKl2J-0002Wj-5A; Fri, 01 Feb 2008 02:49:47 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKl2G-0000YN-Jr; Fri, 01 Feb 2008 02:49:46 +0100 From: Daniel Aleksandersen To: James M Snell Subject: Re: Long list of relations Date: Fri, 1 Feb 2008 02:48:03 +0100 User-Agent: KMail/1.9.5 References: <200802010138.00059.aleksandersen+atomlist@runbox.com> <47A270C8.5040507@gmail.com> In-Reply-To: <47A270C8.5040507@gmail.com> Cc: Atom emailing list Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802010248.03849.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m111noiq063938 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-02-01 02:07, you wrote: > Daniel Aleksandersen wrote: > > Hi emailing list, (message contains Unicode characters) > > [snip] > > > type="application/xhtml+xml" rel="alternate via" /> > > atom:link rel attributes are limited to a single value. You cannot > specify multiple values per link. I thought the atom:link were based on the html4:link element? The HTML 4 specification says that the rel attribute is a spaceâ€separated list of relationship values. Why should the Atom element be different from the HTML element on this attribute? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Thu Jan 31 18:53:56 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D653A67A1 for ; Thu, 31 Jan 2008 18:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Sbo68oJjRb for ; Thu, 31 Jan 2008 18:53:56 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 84D443A6782 for ; Thu, 31 Jan 2008 18:53:54 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m112k0kq067665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 19:46:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m112k0Jm067664; Thu, 31 Jan 2008 19:46:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m112jwJk067655 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 19:46:00 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.161] (helo=patch.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKlug-0001nx-5k for atom-syntax@imc.org; Fri, 01 Feb 2008 03:45:58 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by patch.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKluf-0000MQ-S4 for atom-syntax@imc.org; Fri, 01 Feb 2008 03:45:58 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: Re: Status of the wrapper Date: Fri, 1 Feb 2008 03:44:16 +0100 User-Agent: KMail/1.9.5 References: <200801311143.54164.aleksandersen+atomlist@runbox.com> In-Reply-To: <200801311143.54164.aleksandersen+atomlist@runbox.com> Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802010344.17041.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m112k0Jj067659 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2008-01-31 11:43, Daniel wrote: > Regarding application/xhtml+xml in .… Must I include a full > document type and all? Or is it only the full tree construct > (from that element) that is required? I have not been able to find an answer to this elsewhere, so I am asking the question again. From the html element, or the full thing with doctype declaration? -- Daniel Aleksandersen From owner-atom-syntax@mail.imc.org Thu Jan 31 19:03:03 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F0D3A67A5 for ; Thu, 31 Jan 2008 19:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyRYPRtUs-7f for ; Thu, 31 Jan 2008 19:03:02 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D91FD3A6782 for ; Thu, 31 Jan 2008 19:03:02 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m112tdwF068334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 19:55:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m112tdIB068333; Thu, 31 Jan 2008 19:55:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m112tcYS068327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 19:55:39 -0700 (MST) (envelope-from brian@briansmith.org) Received: from T60 (unknown [71.11.170.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id D7E39D05B1 for ; Thu, 31 Jan 2008 21:55:37 -0500 (EST) From: "Brian Smith" To: "'atom-syntax'" References: <200801311143.54164.aleksandersen+atomlist@runbox.com> <200802010344.17041.aleksandersen+atomlist@runbox.com> Subject: RE: Status of the wrapper Date: Thu, 31 Jan 2008 18:55:37 -0800 Message-ID: <003b01c8647d$ed2df200$0501a8c0@T60> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200802010344.17041.aleksandersen+atomlist@runbox.com> Thread-Index: AchkfMq6lqIBxPo+QWOd5+RoCG0T+wAAOyqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m112tdYR068328 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Aleksandersen wrote: > On 2008-01-31 11:43, Daniel wrote: > > Regarding application/xhtml+xml in .… Must I > include a full > > document type and all? Or is it only the full tree construct > > (from that element) that is required? > > I have not been able to find an answer to this elsewhere, so > I am asking the question again. From the html element, or the > full thing with doctype declaration? You cannot embed a doctype declaration into an XML document. It is illegal syntactically. - Brian From owner-atom-syntax@mail.imc.org Thu Jan 31 20:13:21 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA4228C13D for ; Thu, 31 Jan 2008 20:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Owm34xEV0P4u for ; Thu, 31 Jan 2008 20:13:20 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 941B228C0F0 for ; Thu, 31 Jan 2008 20:13:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1144f2t071592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 21:04:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1144fXL071591; Thu, 31 Jan 2008 21:04:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1144doa071584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2008 21:04:41 -0700 (MST) (envelope-from aleksandersen+atomlist@runbox.com) Received: from [10.9.9.160] (helo=penny.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.50) id 1JKn8o-0001Y9-Rq for atom-syntax@imc.org; Fri, 01 Feb 2008 05:04:38 +0100 Received: from [80.202.178.119] (helo=avernakis.lan) by penny.runbox.com with esmtpsa (uid:642103 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1JKn8o-00037v-Ev for atom-syntax@imc.org; Fri, 01 Feb 2008 05:04:38 +0100 From: Daniel Aleksandersen To: Atom emailing list Subject: atom:id, urn:issn, feed archiving, and uniqueness Date: Fri, 1 Feb 2008 05:02:59 +0100 User-Agent: KMail/1.9.5 Jabber-ID: aleksandersen@jabber.no MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200802010502.59500.aleksandersen+atomlist@runbox.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1144foZ071586 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi emailing list, I think this is a very difficult question. I atom:id-entify the main feed using an ISSN. (See below for example.) This number is unique to my publication and I use it one time per feed. urn:issn:1234-567X But when it comes to atom archiving, it gets a little trickier…. Should I use the same ISSN as for my recent updates feed? The idea of ISSN is that it should uniquely identify all issues of a serial publication. So it would be appropriate to use it in the static feed archives as well as in the continuously update feed. It is not globally unique on a per my feed basis; but it is globally unique on a per…me…basis. If that made any sense to anyone? -- Daniel Aleksandersen From anna.b.morton@myob.com Thu Jan 31 23:05:21 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF8A3A6849 for ; Thu, 31 Jan 2008 23:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 51.76 X-Spam-Level: *************************************************** X-Spam-Status: Yes, score=51.76 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 76.253.160.90] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 76.253.160.90] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 76.253.160.90] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [59.183.183.253 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [59.183.183.253 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwaQsR2CZ5Yv for ; Thu, 31 Jan 2008 23:05:21 -0800 (PST) Received: from triband-mum-59.183.183.253.mtnl.net.in (unknown [59.183.183.253]) by core3.amsl.com (Postfix) with SMTP id 876223A681E for ; Thu, 31 Jan 2008 23:05:17 -0800 (PST) Received: (qmail 26758 invoked from network); Fri, 1 Feb 2008 12:36:56 +0530 Received: from unknown (HELO hcdch) (187.174.74.155) by triband-mum-59.183.183.253.mtnl.net.in with SMTP; Fri, 1 Feb 2008 12:36:56 +0530 Message-ID: <47A2C510.2040006@myob.com> Date: Fri, 1 Feb 2008 12:36:56 +0530 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: atompub-archive@lists.ietf.org Subject: ***SPAM*** 51.76 (5) Eternity of Your Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hugging My Pillow http://76.253.160.90/ From dmiddleton@quest-global.com Thu Jan 31 23:06:52 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F1E3A67E1 for ; Thu, 31 Jan 2008 23:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 44.598 X-Spam-Level: ******************************************** X-Spam-Status: Yes, score=44.598 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_BAD_ID=2.837, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 2.8 RCVD_BAD_ID RCVD_BAD_ID * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 91] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 91] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 67.163.24.155] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [59.183.183.253 listed in zen.spamhaus.org] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 67.163.24.155] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [59.183.183.253 listed in dnsbl.sorbs.net] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx1CsKN+dZQb for ; Thu, 31 Jan 2008 23:06:52 -0800 (PST) Received: from triband-mum-59.183.183.253.mtnl.net.in (unknown [59.183.183.253]) by core3.amsl.com (Postfix) with SMTP id 0C2FE3A681E for ; Thu, 31 Jan 2008 23:06:50 -0800 (PST) Received: from [132.25.205.66] (helo=pdnx) by triband-mum-59.183.183.253.mtnl.net.in with smtp (Exim 4.62 (FreeBSD)) id 1JLY%6-0002kU-A5; Fri, 1 Feb 2008 12:39:54 +0530 Message-ID: <002c01c864a1$3f385db0$42cd1984@pdnx> From: To: Subject: ***SPAM*** 44.598 (5) Sending You All My Love Date: Fri, 1 Feb 2008 12:38:29 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Surrounded by Love http://67.163.24.155/ From zetrofno@AEW.COM Thu Jan 31 23:37:37 2008 Return-Path: X-Original-To: ietfarch-atompub-archive@core3.amsl.com Delivered-To: ietfarch-atompub-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0953A685A for ; Thu, 31 Jan 2008 23:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 89.769 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=89.769 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_DYNAMIC=0.1, SARE_SXLIFE=1.07, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.6 HOST_EQ_SK HOST_EQ_SK * 1.4 HELO_EQ_SK HELO_EQ_SK * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.1 SARE_SXLIFE BODY: Talks about your sex life * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: canregit.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: canregit.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: canregit.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: canregit.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: canregit.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: canregit.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: canregit.com] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUBy0rbJ+Q7s for ; Thu, 31 Jan 2008 23:37:36 -0800 (PST) Received: from ppp-77-234-225-4.dsidata.sk (ppp-77-234-225-4.dsidata.sk [77.234.225.4]) by core3.amsl.com (Postfix) with ESMTP id 419133A6811 for ; Thu, 31 Jan 2008 23:37:35 -0800 (PST) Message-ID: <000b01c864a5$8d7e3860$04e1ea4d@seligaj> From: "Naveed guitard" To: atompub-archive@lists.ietf.org Subject: ***SPAM*** 89.769 (5) Complete your life with total sexual enjoyment for you and your partner Date: Fri, 1 Feb 2008 08:39:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C864AD.EF42A060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0007_01C864AD.EF42A060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Real Men have Real Big Dcks, are you a Real Man? ----------=_NextPart_000_0007_01C864AD.EF42A060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Real Men have Real Big Dcks, are = you a Real=20 Man? ----------=_NextPart_000_0007_01C864AD.EF42A060--