From owner-atom-syntax@mail.imc.org Mon Oct 02 02:17:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUH7K-00007o-8h for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 02:17:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUH7G-0000KH-JY for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 02:17:30 -0400 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 k925rTVs034364; Sun, 1 Oct 2006 22:53: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 k925rTMc034363; Sun, 1 Oct 2006 22:53: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 mail.internode.on.net (bld-mail01.adl2.internode.on.net [203.16.214.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k925rOr8034281 for ; Sun, 1 Oct 2006 22:53:25 -0700 (MST) (envelope-from arsptr@internode.on.net) Received: from [192.168.1.3] (unverified [59.167.25.208]) by mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 237278988 for multiple; Mon, 02 Oct 2006 15:23:16 +0930 (CST) In-Reply-To: <451AE153.4080108@gmail.com> References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-2-1072568623 Message-Id: Cc: Bill de hOra , atom-syntax@imc.org From: Alastair Rankine Subject: Re: Atom Export Date: Mon, 2 Oct 2006 15:53:14 +1000 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 --Apple-Mail-2-1072568623 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for the initial feedback. It is a common dilemma for spec writers to decide when to stop. In this case: should the spec include non-atom resources or not? I initially thought not because it didn't seem to fit easily but perhaps I was too hasty. There are some potential users of this whose important content is almost exclusively in binary format, such as podcasters. On reflection it seems an unwise exclusion. So I haven't thought about this much either, but a couple of options present themselves. As you say below, zipfiles may be a good solution. There is also the XOP format (http://www.w3.org/TR/xop10/) which looks pretty suitable also. Of these two I lean towards zip, but I would have to think about it some more. Any other suggestions or comments? On 28/09/2006, at 6:38 AM, James M Snell wrote: > > I haven't done much deep thinking about this proposal yet, but the one > thing that concerns me are the non-atom resources that go along > with the > entries. When I export from a blog, I want to be able to export > everything in a single operation. I've been stewing lately over the > possibility of doing something similar to this but wrapping the atom > documents and associated resources into a zip. A single master atom > feed would provide an index of the archive, with individual entries > either contained in that index feed or as separate entry documents > (modeled loosely after the distinction app makes between the > collection > feed and individual editable entries. > > - James > > Bill de hOra wrote: >> >> Alastair Rankine wrote: >>> >>> Hello Atom folks, >>> >>> Here is a proposal for an Atom-derived format for exporting of >>> content. >>> >>> The problem I'm trying to solve is that of migration from one >>> authoring system (eg blogging engine) to another. Atom is highly >>> suited to this task. >>> >>> The full problem statement, and the reasons for basing the >>> solution on >>> Atom, are all described in the proposal published here: >>> >>> http://girtby.net/offerings/atomexport >>> >>> There is no implementation yet. >>> >>> I look forward to your comments on this document. >> >> >> Very quickly (I'm overloaded atm) - this is excellent. >> >> I've been looking at using Atom Entries for roundtripping/backup and >> interchange, especially in CMSes, for some time. The ultimate dump >> format in terms of expressiveness is RDF/XML, but it can be >> complicated. >> Atom offers a lot of value with comparative simplicity largely >> because >> atom:id can survive across systems*, but also because the flat >> format of >> entries maps well onto relational data (it's particularly good for >> dumping metadata). One hard problem is in usefully storing and >> indexing >> received foreign markup. >> >> cheers >> Bill >> >> * that said, for "consumer" data, the APP leans towards, or least >> allows, rewriting of atom:ids due to trust issues. >> >> --Apple-Mail-2-1072568623 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Thanks for the initial = feedback.

It = is a common=A0dilemma for spec writers to decide when to stop. In this = case: should the spec include non-atom resources or not?

I initially thought not = because it didn't seem to fit easily but perhaps I was too hasty. There = are some potential users of this whose important content is almost = exclusively in binary format, such as podcasters. On reflection it seems = an unwise exclusion.

So I haven't thought about = this much either, but a couple of options present themselves. As you say = below, zipfiles may be a good solution. There is also the XOP = format=A0(http://www.w3.org/TR/xop10/) = which looks pretty suitable also.=A0Of these two I lean towards zip, but = I would have to think about it some more.

Any other suggestions or = comments?


On = 28/09/2006, at 6:38 AM, James M Snell wrote:


I = haven't done much deep thinking about this proposal yet, but the = one
thing that concerns me are the = non-atom resources that go along with the
=A0 When I export = from a blog, I want to be able to export
=A0= I've been stewing lately over the
documents and associated = resources into a zip.=A0 A = single master atom
feed would provide an index = of the archive, with individual entries
either = contained in that index feed or as separate entry documents
(modeled loosely after the distinction app makes = between the collection
feed and individual = editable entries.

- James

Bill de hOra wrote:
=
Alastair Rankine wrote:
=
Hello Atom folks,

Here is = a proposal for an Atom-derived format for exporting of = content.

The problem I'm trying to solve is that of migration = from one
authoring system (eg blogging = engine) to another. Atom is highly
suited to = this task.

The full problem statement, and the reasons for = basing the solution on
Atom, are all described in = the proposal published here:


There is no implementation yet.

I look = forward to your comments on this document.


Very quickly = (I'm overloaded atm) - this is excellent.

I've been = looking at using Atom Entries for roundtripping/backup and
interchange, especially in CMSes, for some time. The = ultimate dump
format in terms of = expressiveness is RDF/XML, but it can be complicated.
Atom offers a lot of value with comparative = simplicity largely because
atom:id can = survive across systems*, but also because the flat format of
entries maps well onto relational data (it's = particularly good for
dumping metadata). One hard = problem is in usefully storing and indexing

cheers
Bill

* that said, for "consumer" = data, the APP leans towards, or least
allows, = rewriting of atom:ids due to trust issues.



= --Apple-Mail-2-1072568623-- From owner-atom-syntax@mail.imc.org Mon Oct 02 02:21:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUHAu-0002lp-T1 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 02:21:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUHAr-0001CE-CV for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 02:21:12 -0400 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 k9267fwh037648; Sun, 1 Oct 2006 23:07: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 k9267f36037647; Sun, 1 Oct 2006 23:07: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 py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9267eXt037633 for ; Sun, 1 Oct 2006 23:07:40 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so2082436pye for ; Sun, 01 Oct 2006 23:07:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=I4Zj5bMrMckhTLZVbhWLCs5hY5hNYJDkNIvAKqyJrfBX7ExH+wAg6rOlPzks/iFflKK+qSxjYGoglJ/Uup8pqSoZysqMs8gpm/dHSYaBZkmIc46pofqvNIsZ4iNvo0bLqnP5ahD1VcNC6iCo9FCgP1efjqxXyObvq8sziYn/FWw= Received: by 10.65.248.19 with SMTP id a19mr6650419qbs; Sun, 01 Oct 2006 23:07:39 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id e13sm5420388qbe.2006.10.01.23.07.37; Sun, 01 Oct 2006 23:07:38 -0700 (PDT) Message-ID: <4520AC9A.9090001@gmail.com> Date: Sun, 01 Oct 2006 23:07:22 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Alastair Rankine CC: Bill de hOra , atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> In-Reply-To: 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: 10ba05e7e8a9aa6adb025f426bef3a30 Using XOP is definitely an option, but it's one that is likely to be far less efficient and likely quite a bit more complicated than a zip. Using the zip gives you quite a few options for exporting multiple collections, with associated resources, templates, configuration settings, plugins, whatever. Exporting the media resources is, at the very least, a very important requirement for the types of cases we'd be looking at to use this. - James Alastair Rankine wrote: > Thanks for the initial feedback. > > It is a common dilemma for spec writers to decide when to stop. In this > case: should the spec include non-atom resources or not? > > I initially thought not because it didn't seem to fit easily but perhaps > I was too hasty. There are some potential users of this whose important > content is almost exclusively in binary format, such as podcasters. On > reflection it seems an unwise exclusion. > > So I haven't thought about this much either, but a couple of options > present themselves. As you say below, zipfiles may be a good solution. > There is also the XOP format (http://www.w3.org/TR/xop10/) which looks > pretty suitable also. Of these two I lean towards zip, but I would have > to think about it some more. > > Any other suggestions or comments? > > > On 28/09/2006, at 6:38 AM, James M Snell wrote: > >> >> I haven't done much deep thinking about this proposal yet, but the one >> thing that concerns me are the non-atom resources that go along with the >> entries. When I export from a blog, I want to be able to export >> everything in a single operation. I've been stewing lately over the >> possibility of doing something similar to this but wrapping the atom >> documents and associated resources into a zip. A single master atom >> feed would provide an index of the archive, with individual entries >> either contained in that index feed or as separate entry documents >> (modeled loosely after the distinction app makes between the collection >> feed and individual editable entries. >> >> - James >> >> Bill de hOra wrote: >>> >>> Alastair Rankine wrote: >>>> >>>> Hello Atom folks, >>>> >>>> Here is a proposal for an Atom-derived format for exporting of content. >>>> >>>> The problem I'm trying to solve is that of migration from one >>>> authoring system (eg blogging engine) to another. Atom is highly >>>> suited to this task. >>>> >>>> The full problem statement, and the reasons for basing the solution on >>>> Atom, are all described in the proposal published here: >>>> >>>> http://girtby.net/offerings/atomexport >>>> >>>> There is no implementation yet. >>>> >>>> I look forward to your comments on this document. >>> >>> >>> Very quickly (I'm overloaded atm) - this is excellent. >>> >>> I've been looking at using Atom Entries for roundtripping/backup and >>> interchange, especially in CMSes, for some time. The ultimate dump >>> format in terms of expressiveness is RDF/XML, but it can be complicated. >>> Atom offers a lot of value with comparative simplicity largely because >>> atom:id can survive across systems*, but also because the flat format of >>> entries maps well onto relational data (it's particularly good for >>> dumping metadata). One hard problem is in usefully storing and indexing >>> received foreign markup. >>> >>> cheers >>> Bill >>> >>> * that said, for "consumer" data, the APP leans towards, or least >>> allows, rewriting of atom:ids due to trust issues. >>> >>> > From owner-atom-syntax@mail.imc.org Mon Oct 02 03:19:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUI5G-0005MM-T3 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 03:19:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUI5F-0007t9-IH for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 03:19:26 -0400 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 k9271YRb047918; Mon, 2 Oct 2006 00:01: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 k9271YMb047917; Mon, 2 Oct 2006 00:01: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 omta14.mta.everyone.net (sitemail2.everyone.net [216.200.145.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9271X0Y047906 for ; Mon, 2 Oct 2006 00:01:33 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from dm21.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta14.mta.everyone.net (Postfix) with ESMTP id 688FB409F1 for ; Mon, 2 Oct 2006 00:01:33 -0700 (PDT) X-Eon-Dm: dm21 Received: by dm21.mta.everyone.net (EON-AUTHRELAY2 - 45568b9c) id dm21.45208a19.b369 for ; Mon, 2 Oct 2006 00:01:33 -0700 X-Eon-Sig: AQKyyCtFILlNurTkIgIAAAAB,08f12f234207c4081ce9de1be8e3ebc4 Message-ID: <4520B94C.6020209@mozilla.com> Date: Mon, 02 Oct 2006 03:01:32 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Atom Syndication Format To Draft Standard? 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: 30ac594df0e66ffa5a93eb4c48bcb014 I think we should move the format to Draft Standard by clearing up any errata and adding two attributes: 'dir' and 'unicode-bidi', as defined in XHTML. Thoughts? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 02 03:42:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIRw-0002nO-PG for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 03:42:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUIMc-00014v-Pm for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 03:37:30 -0400 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 k927LHtx050122; Mon, 2 Oct 2006 00:21: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 k927LHH9050121; Mon, 2 Oct 2006 00:21: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k927LFCa050110 for ; Mon, 2 Oct 2006 00:21:16 -0700 (MST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 02 Oct 2006 07:21:09 -0000 Received: from dslb-084-056-250-185.pools.arcor-ip.net (EHLO hive) [84.56.250.185] by mail.gmx.net (mp028) with SMTP; 02 Oct 2006 09:21:09 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Robert Sayre Cc: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? Date: Mon, 02 Oct 2006 09:21:09 +0200 Message-ID: <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> References: <4520B94C.6020209@mozilla.com> In-Reply-To: <4520B94C.6020209@mozilla.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 k927LHtx050122 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f * Robert Sayre wrote: >I think we should move the format to Draft Standard by clearing up any=20 >errata and adding two attributes: 'dir' and 'unicode-bidi', as defined=20 >in XHTML. > >Thoughts? I "think" that XHTML does not define an 'unicode-bidi' attribute. Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"? --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Mon Oct 02 03:57:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUIgA-0005uu-Lg for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 03:57:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUIg8-0004cI-9u for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 03:57:34 -0400 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 k927aBLm053394; Mon, 2 Oct 2006 00:36: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 k927aBNY053393; Mon, 2 Oct 2006 00:36: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 py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k927aAqn053386 for ; Mon, 2 Oct 2006 00:36:11 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so2107764pye for ; Mon, 02 Oct 2006 00:36:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qAx34LdsdITCh2aJeUDwkcK7PdNwqD7J4LnRLy0W9f5yaq51bJ7BYAJyJM2/3UB5gGDdrYvbDJbszIZkFEGo2kH1OdaXx5XcmD+FdLbP2OfSZbCVJ7vgwbUIkA7FReTxlno74gwdTwJB8Ir+KKOgVApFQVxsHwzW2pic3kUsFL8= Received: by 10.65.240.5 with SMTP id s5mr2324093qbr; Mon, 02 Oct 2006 00:36:10 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id e16sm5558766qba.2006.10.02.00.36.09; Mon, 02 Oct 2006 00:36:10 -0700 (PDT) Message-ID: <4520C15A.70907@gmail.com> Date: Mon, 02 Oct 2006 00:35:54 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> In-Reply-To: <4520B94C.6020209@mozilla.com> 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Robert Sayre wrote: > > I think we should move the format to Draft Standard by clearing up any > errata and adding two attributes: 'dir' and 'unicode-bidi', as defined > in XHTML. Are you suggesting adding these to the common attributes or to Text constructs and atom:content specifically? - James From owner-atom-syntax@mail.imc.org Mon Oct 02 04:27:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJ9b-0005Za-Rv for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 04:27:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUJ9T-0000uV-G0 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 04:27:59 -0400 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 k928CoqU058485; Mon, 2 Oct 2006 01:12: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 k928Colb058484; Mon, 2 Oct 2006 01:12: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k928Cmll058477 for ; Mon, 2 Oct 2006 01:12:49 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 Oct 2006 08:12:42 -0000 Received: from xdsl-213-196-245-20.netcologne.de (EHLO klangraum) [213.196.245.20] by mail.gmx.net (mp027) with SMTP; 02 Oct 2006 10:12:42 +0200 X-Authenticated: #163624 Date: Mon, 2 Oct 2006 10:12:41 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Atom Export Message-ID: <20061002081241.GB2624@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451AE153.4080108@gmail.com> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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: 7d33c50f3756db14428398e2bdedd581 * James M Snell [2006-09-29 14:17]: > I've been stewing lately over the possibility of doing > something similar to this but wrapping the atom documents and > associated resources into a zip. A single master atom feed > would provide an index of the archive, with individual entries > either contained in that index feed or as separate entry > documents Why the zip? Atom is an envelope format that can transport binary content. So is tar. Just gzip the Atom feed; instead of .tar.gz (which usually compresses better than zips) you get .atom.gz. Hmm. Maybe we should call these Atomballs? Buckminsterfullerenes? :-) Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Oct 02 05:46:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKNB-00018o-5j for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 05:46:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKN1-0003rs-Q9 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 05:46:05 -0400 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 k929SiaG074372; Mon, 2 Oct 2006 02:28: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 k929SiNq074371; Mon, 2 Oct 2006 02:28: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 pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k929SgDP074314 for ; Mon, 2 Oct 2006 02:28:43 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 2 Oct 2006 17:25:36 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 02 Oct 2006 17:23:28 +1000 Subject: Re: Atom Syndication Format To Draft Standard? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4520B94C.6020209@mozilla.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 2/10/06 5:01 PM, "Robert Sayre" wrote: > I think we should move the format to Draft Standard by clearing up any > errata and adding two attributes: 'dir' and 'unicode-bidi', as defined > in XHTML. add @attr where? e. From owner-atom-syntax@mail.imc.org Mon Oct 02 10:42:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOzr-0002lQ-7I for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:42:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOzm-0002Fn-R9 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:42:19 -0400 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 k92ELX0b032803; Mon, 2 Oct 2006 07:21: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 k92ELXuu032802; Mon, 2 Oct 2006 07:21: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 mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92ELWPe032785 for ; Mon, 2 Oct 2006 07:21:32 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 17135 invoked from network); 2 Oct 2006 14:21:26 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 Oct 2006 14:21:26 -0000 Message-ID: <45212065.3050203@metalab.unc.edu> Date: Mon, 02 Oct 2006 10:21:25 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James M Snell CC: Alastair Rankine , Bill de hOra , atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> In-Reply-To: <4520AC9A.9090001@gmail.com> 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 k92ELX0b032803 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a James M Snell wrote: > Using XOP is definitely an option, but it's one that is likely to be fa= r > less efficient and likely quite a bit more complicated than a zip. > Using the zip gives you quite a few options for exporting multiple > collections, with associated resources, templates, configuration > settings, plugins, whatever. Exporting the media resources is, at the > very least, a very important requirement for the types of cases we'd be > looking at to use this. >=20 XOP, if I understand it correctly, could in fact be packaged in a zip=20 file, though no such packaging is described in the spec. If you went=20 with a non-XOP zip as opposed to XOP, I suspect you'd probably end up=20 reinventing a lot of XOP along the way. If you could get away with 20%=20 of XOP, then it might be worthwhile to do something custom. Otherwise,=20 I'd just go with XOP. Another possibility: OpenOffice does something very much like this=20 (zipped XML + media). Does anyone know if that format is sufficiently=20 generic to handle this use case? --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai= tA/ From owner-atom-syntax@mail.imc.org Mon Oct 02 10:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP0V-0005R4-OQ for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:42:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP0U-0002K6-Bj for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:42:59 -0400 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 k92ERixZ036057; Mon, 2 Oct 2006 07:27: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 k92ERiWE036056; Mon, 2 Oct 2006 07:27: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 mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92ERfkA036006 for ; Mon, 2 Oct 2006 07:27:44 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 22341 invoked from network); 2 Oct 2006 14:27:36 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 Oct 2006 14:27:36 -0000 Message-ID: <452121D8.3030509@metalab.unc.edu> Date: Mon, 02 Oct 2006 10:27:36 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <20061002081241.GB2624@klangraum> In-Reply-To: <20061002081241.GB2624@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 k92ERixZ036057 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 A. Pagaltzis wrote: > Why the zip? Atom is an envelope format that can transport binary > content.=20 No, it isn't. An atom envelope can point to non-XML data binary data,=20 but it cannot reasonably embed it. You could use an atomLink element to=20 point to the binary data; then embed the whole file set in a zip file.=20 Maybe that's all that really needed. However, you would need that extra=20 level of packaging. I suppose you could base64 encode everything in a big atom:entry; but=20 that's a lot of extra work for no particular point. It would essentially=20 rule out using DOM to process this stuff, for example. Better to let=20 MP3s, MPEGs, and other non-XML media to reside elsewhere and just let=20 the XML point to it. --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai= tA/ From owner-atom-syntax@mail.imc.org Mon Oct 02 10:47:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP5E-0000h1-94 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:47:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP5C-0002ix-Sp for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:47:52 -0400 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 k92EVKen036672; Mon, 2 Oct 2006 07: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 k92EVK44036671; Mon, 2 Oct 2006 07: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 mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92EVJ4W036652 for ; Mon, 2 Oct 2006 07:31:19 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 7906 invoked from network); 2 Oct 2006 14:31:13 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 2 Oct 2006 14:31:13 -0000 Message-ID: <452122B1.2070907@metalab.unc.edu> Date: Mon, 02 Oct 2006 10:31:13 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> In-Reply-To: <4520B94C.6020209@mozilla.com> 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 k92EVKen036672 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Robert Sayre wrote: >=20 > I think we should move the format to Draft Standard by clearing up any=20 > errata and adding two attributes: 'dir' and 'unicode-bidi', as defined=20 > in XHTML. >=20 Which elements would these be attached to? Also, I'm not familiar with the unicode-bidi attribute. Do you have a=20 reference for it? Which version of XHTML is that in? Do you mean the CSS=20 unicode-bidi property? --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai= tA/ From owner-atom-syntax@mail.imc.org Mon Oct 02 11:32:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPm1-00068w-TK for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 11:32:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPlz-0000aI-Hc for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 11:32:05 -0400 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 k92FHY8k052897; Mon, 2 Oct 2006 08:17: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 k92FHXTs052893; Mon, 2 Oct 2006 08:17: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 omta16.mta.everyone.net (sitemail2.everyone.net [216.200.145.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92FHRA9052855 for ; Mon, 2 Oct 2006 08:17:29 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from dm16.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta16.mta.everyone.net (Postfix) with ESMTP id 38B034095C; Mon, 2 Oct 2006 08:17:19 -0700 (PDT) X-Eon-Dm: dm16 Received: by dm16.mta.everyone.net (EON-AUTHRELAY2 - 45568b9c) id dm16.45208a0a.1abb4; Mon, 2 Oct 2006 08:17:19 -0700 X-Eon-Sig: AQKyyCtFIS1/jXw/VQIAAAAC,ba0327e7d4f7a96d1d87cf63567aea54 Message-ID: <45212D7D.2000604@mozilla.com> Date: Mon, 02 Oct 2006 11:17:17 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Bjoern Hoehrmann Cc: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> In-Reply-To: <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> 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: 9466e0365fc95844abaf7c3f15a05c7d Bjoern Hoehrmann wrote: > > I "think" that XHTML does not define an 'unicode-bidi' attribute. > Do you mean, for 'unicode-bidi', "as defined in CSS 2.1"? > Sure. Elliotte Harold wrote: > > Which elements would these be attached to? All of them. Paul Hoffman wrote: > At 3:01 AM -0400 10/2/06, Robert Sayre wrote: >> I think we should move the format to Draft Standard by clearing up >> any errata and adding two attributes: 'dir' and 'unicode-bidi', as >> defined in XHTML. > > We can't both add features and move to Draft Standard at the same time. Dang, where'd that rule come from? It would probably be easier to add them in a separate document, huh? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 02 11:47:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQ1I-0002v4-23 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 11:47:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPNO-0005lS-2A for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 11:06:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GUPEW-0005lW-LI for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 10:57:31 -0400 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 k92EbSRX037511; Mon, 2 Oct 2006 07:37: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 k92EbSrt037510; Mon, 2 Oct 2006 07:37: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 [10.20.30.183] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92EbGtK037486; Mon, 2 Oct 2006 07:37:16 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4520B94C.6020209@mozilla.com> References: <4520B94C.6020209@mozilla.com> Date: Mon, 2 Oct 2006 07:37:12 -0700 To: Robert Sayre , atom-syntax@imc.org From: Paul Hoffman Subject: Re: Atom Syndication Format To Draft Standard? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.0 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 At 3:01 AM -0400 10/2/06, Robert Sayre wrote: >I think we should move the format to Draft Standard by clearing up >any errata and adding two attributes: 'dir' and 'unicode-bidi', as >defined in XHTML. We can't both add features and move to Draft Standard at the same time. If we add features, we would recycle at Proposed Standard. Errata that are truly that and not technical changes can be made when moving to Draft Standard. From owner-atom-syntax@mail.imc.org Mon Oct 02 11:52:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQ5M-0006K9-Kb for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 11:52:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQ5K-0003Iy-7h for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 11:52:04 -0400 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 k92FUGsN061582; Mon, 2 Oct 2006 08:30: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 k92FUGEd061581; Mon, 2 Oct 2006 08:30: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-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92FUEL8061575 for ; Mon, 2 Oct 2006 08:30:15 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so549864nzp for ; Mon, 02 Oct 2006 08:30:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=R7ExDqfC7gRwxVLyZ83WgF3DfNg/rZ+YRBcU1IzKImz9Vt60Vumiq0tLHrOMGpnUTJKzYtP01fUWOKKqfIShr4B7Xc8OJsYhOQqGqlJrl50QYKJ7OAaYQSIAara7b5stEXbLSOC0AcH73XiD8vskKFdSnmg7humpxtmQJlqmEOg= Received: by 10.65.219.14 with SMTP id w14mr7268164qbq; Mon, 02 Oct 2006 08:30:14 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id e15sm6083208qbe.2006.10.02.08.30.13; Mon, 02 Oct 2006 08:30:14 -0700 (PDT) Message-ID: <45213075.5000307@gmail.com> Date: Mon, 02 Oct 2006 08:29:57 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Elliotte Harold CC: atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <20061002081241.GB2624@klangraum> <452121D8.3030509@metalab.unc.edu> In-Reply-To: <452121D8.3030509@metalab.unc.edu> 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: 93238566e09e6e262849b4f805833007 +1 Elliotte Harold wrote: > > A. Pagaltzis wrote: > >> Why the zip? Atom is an envelope format that can transport binary >> content. > > > No, it isn't. An atom envelope can point to non-XML data binary data, > but it cannot reasonably embed it. You could use an atomLink element to > point to the binary data; then embed the whole file set in a zip file. > Maybe that's all that really needed. However, you would need that extra > level of packaging. > > I suppose you could base64 encode everything in a big atom:entry; but > that's a lot of extra work for no particular point. It would essentially > rule out using DOM to process this stuff, for example. Better to let > MP3s, MPEGs, and other non-XML media to reside elsewhere and just let > the XML point to it. > From owner-atom-syntax@mail.imc.org Mon Oct 02 12:31:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQhh-0002WG-Tj for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 12:31:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQhf-0001MI-HJ for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 12:31:41 -0400 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 k92Fr196069304; Mon, 2 Oct 2006 08:53: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 k92Fr18g069303; Mon, 2 Oct 2006 08:53: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 [10.20.30.183] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92Fqxga069290 for ; Mon, 2 Oct 2006 08:53:00 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <45212D7D.2000604@mozilla.com> References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.com> Date: Mon, 2 Oct 2006 08:52:56 -0700 To: atom-syntax@imc.org From: Paul Hoffman Subject: Re: Atom Syndication Format To Draft Standard? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab At 11:17 AM -0400 10/2/06, Robert Sayre wrote: >Paul Hoffman wrote: >>At 3:01 AM -0400 10/2/06, Robert Sayre wrote: >>>I think we should move the format to Draft Standard by clearing up >>>any errata and adding two attributes: 'dir' and 'unicode-bidi', as >>>defined in XHTML. >> >>We can't both add features and move to Draft Standard at the same time. > >Dang, where'd that rule come from? Probably RFC 2026, but if not there, it is certainly in the folklore of How Things Are Done. >It would probably be easier to add them in a separate document, huh? Maybe, but that would then confuse the issue by having two docs people would expect to have read in order to do the format. Given the very marginal value of Draft Standard, we should probably just revise and recycle at Proposed rather than split into two. From owner-atom-syntax@mail.imc.org Mon Oct 02 14:48:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUSqA-0003FQ-Gb for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 14:48:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUSq7-0000Nj-1u for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 14:48:34 -0400 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 k92IVKxB025851; Mon, 2 Oct 2006 11: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 k92IVKQ5025850; Mon, 2 Oct 2006 11: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 ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92IVIsO025834 for ; Mon, 2 Oct 2006 11:31:19 -0700 (MST) (envelope-from ga-atom-syntax@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GUSYF-0004sO-L2 for atom-syntax@imc.org; Mon, 02 Oct 2006 20:30:04 +0200 Received: from user-10876hc.cable.mindspring.com ([64.131.154.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 20:30:03 +0200 Received: from rsayre by user-10876hc.cable.mindspring.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Oct 2006 20:30:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Robert Sayre Subject: Re: Atom Syndication Format To Draft Standard? Date: Mon, 2 Oct 2006 18:23:14 +0000 (UTC) Lines: 30 Message-ID: References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 64.131.154.44 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Paul Hoffman writes: > > Probably RFC 2026, but if not there, it is certainly in the folklore > of How Things Are Done. That's unfortunate. A documented process is a requirement for open standards development, in the opinion of many > > >It would probably be easier to add them in a separate document, huh? > > Maybe, but that would then confuse the issue by having two docs > people would expect to have read in order to do the format. Given the > very marginal value of Draft Standard, we should probably just revise > and recycle at Proposed rather than split into two. There is one mistake in the Relax NG (atom common attributes on author or something) and at least one section that is somewhat unclear around the external div in XHTML. The i18n attributes seem needed to display text without a guess based on xml:lang. Maybe we don't even need unicode-bidi. I don't think it would be smart to take other features. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 02 15:23:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTOG-0002z7-Sv for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:23:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTOF-00047H-Ed for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:23:48 -0400 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 k92J6qex031613; Mon, 2 Oct 2006 12:06: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 k92J6qi1031612; Mon, 2 Oct 2006 12:06: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.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k92J6oTG031596 for ; Mon, 2 Oct 2006 12:06:51 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Oct 2006 19:06:45 -0000 Received: from p508FBE6D.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.190.109] by mail.gmx.net (mp004) with SMTP; 02 Oct 2006 21:06:45 +0200 X-Authenticated: #1915285 Message-ID: <4521634A.2080409@gmx.de> Date: Mon, 02 Oct 2006 21:06:50 +0200 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: Paul Hoffman CC: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Paul Hoffman schrieb: >> Dang, where'd that rule come from? > > Probably RFC 2026, but if not there, it is certainly in the folklore of > How Things Are Done. > ... I thought this is possible if interop is demonstrated... > ... Best regards, Julian From owner-atom-syntax@mail.imc.org Mon Oct 02 15:24:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTPE-0004AT-Ef for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:24:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTPD-0004GA-1W for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:24:48 -0400 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 k92JAKrC031965; Mon, 2 Oct 2006 12:10: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 k92JAKLk031964; Mon, 2 Oct 2006 12:10: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k92JAHHu031946 for ; Mon, 2 Oct 2006 12:10:18 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Oct 2006 19:10:12 -0000 Received: from p508FBE6D.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.190.109] by mail.gmx.net (mp043) with SMTP; 02 Oct 2006 21:10:12 +0200 X-Authenticated: #1915285 Message-ID: <45216418.9020507@gmx.de> Date: Mon, 02 Oct 2006 21:10:16 +0200 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: Paul Hoffman CC: Robert Sayre , atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: f4c2cf0bccc868e4cc88dace71fb3f44 Paul Hoffman schrieb: > > At 3:01 AM -0400 10/2/06, Robert Sayre wrote: >> I think we should move the format to Draft Standard by clearing up any >> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined >> in XHTML. > > We can't both add features and move to Draft Standard at the same time. > If we add features, we would recycle at Proposed Standard. Errata that > are truly that and not technical changes can be made when moving to > Draft Standard. > ... Independantly of that, what do we do with all the normative references to proposed standards...: Normative References: REC-html401-19991224: [REC] ok RFC4288: [BEST CURRENT PRACTICE] (-> BCP0013) RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) RFC2822: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! RFC2854: [INFORMATIONAL] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3023: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3066: [BEST CURRENT PRACTICE] obsoleted by RFC4646 RFC4647 RFC3339: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3548: [INFORMATIONAL] -- intended standards level of DRAFT incompatible with this document's standard level! RFC3986: [STANDARD] (-> STD0066) RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! REC-xml-20040204: [REC] ok REC-xml-c14n-20010315: [REC] ok REC-xml-exc-c14n-20020718: [REC] ok REC-xml-infoset-20040204: [REC] ok REC-xml-names-19990114: [REC] ok REC-xmlbase-20010627: [REC] ok REC-xmldsig-core-20020212: [REC] ok REC-xmlenc-core-20021210: [REC] ok REC-xhtml-modularization-20010410: document unknown Informative References: ISO.8601.1988: not checked RELAX-NG: not checked RFC2434: [BEST CURRENT PRACTICE] (-> BCP0026) NOTE-datetime-19980827: document unknown REC-xmlschema-2-20041028: [REC] ok ? Best regards, Julian From owner-atom-syntax@mail.imc.org Mon Oct 02 15:33:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTY6-0002qu-Jc for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:33:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTY4-0005aD-5x for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:33:58 -0400 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 k92JJqhM032644; Mon, 2 Oct 2006 12:19: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 k92JJqFe032643; Mon, 2 Oct 2006 12:19: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JJnND032635 for ; Mon, 2 Oct 2006 12:19:51 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so64556wxc for ; Mon, 02 Oct 2006 12:19:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FIzXYiWMBNwFysaD3Y+9szEGXP0v7TtksJfXryVGhlgftdkv8nYyuH0/3nHmXiA5MPMgCnyRG8+W0Uud7ByjzqJKUu49hA1lvyER2cUNICsZokf/jsTJI1vwltfVVmdSGehyBV/kK5F6o/GG8+gj6ZWxKobYEqUNoIV21b4pGbc= Received: by 10.90.113.18 with SMTP id l18mr3131433agc; Mon, 02 Oct 2006 12:19:48 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g7sm8219853wra.2006.10.02.12.19.47; Mon, 02 Oct 2006 12:19:48 -0700 (PDT) Message-ID: <45216643.8050208@gmail.com> Date: Mon, 02 Oct 2006 12:19:31 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.com> In-Reply-To: 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: 7d33c50f3756db14428398e2bdedd581 I would definitely agree that having a dir attribute would be a good thing. (would be even better if it were defined as xml:dir but... whatever). I'm not so sure about unicode-bidi. - James Robert Sayre wrote: > [snip] > The i18n attributes seem needed to display text without a guess based on > xml:lang. Maybe we don't even need unicode-bidi. I don't think it would be > smart to take other features. > > Robert Sayre > > > > From owner-atom-syntax@mail.imc.org Mon Oct 02 15:41:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTfk-0001pK-7g for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:41:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTfi-0006bn-RK for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:41:52 -0400 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 k92JRb32035371; Mon, 2 Oct 2006 12:27: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 k92JRY4A035300; Mon, 2 Oct 2006 12:27: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 [10.20.30.183] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JRTGW035196; Mon, 2 Oct 2006 12:27:30 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.com> Date: Mon, 2 Oct 2006 12:27:25 -0700 To: Robert Sayre , atom-syntax@imc.org From: Paul Hoffman Subject: Re: Atom Syndication Format To Draft Standard? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 At 6:23 PM +0000 10/2/06, Robert Sayre wrote: >That's unfortunate. A documented process is a requirement for open standards >development, in the opinion of many If it is a true requirement, then I guess the IETF is an abysmal failure. Oh, well. OTOH, some folks in the IETF are trying to meet the desire by doing a better job of codifying what is and is not the process. Others, I must admit, are not trying at all. >There is one mistake in the Relax NG (atom common attributes on author or >something) and at least one section that is somewhat unclear around >the external >div in XHTML. I believe both of those would be considered clarifications, and thus not prevent the movement to Draft Standard. >The i18n attributes seem needed to display text without a guess based on >xml:lang. Maybe we don't even need unicode-bidi. I don't think it would be >smart to take other features. "needed to display" is often an issue the IETF ignores, so we might avoid it if the desire is to get to Draft Standard. But Julian's second message needs to be dealt with first, and I assure you that many of those documents are not going to be going to Draft Standard any time soon (if ever) because there is no energy to test every required feature in the documents. From owner-atom-syntax@mail.imc.org Mon Oct 02 15:46:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTk0-0004cE-2X for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:46:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTjy-0006l6-Mh for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 15:46:16 -0400 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 k92JXVoT036299; Mon, 2 Oct 2006 12:33: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 k92JXVRZ036298; Mon, 2 Oct 2006 12:33: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 omta14.mta.everyone.net (sitemail2.everyone.net [216.200.145.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JXUm6036276; Mon, 2 Oct 2006 12:33:30 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from dm21.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta14.mta.everyone.net (Postfix) with ESMTP id 1B3E740D04; Mon, 2 Oct 2006 12:33:27 -0700 (PDT) X-Eon-Dm: dm21 Received: by dm21.mta.everyone.net (EON-AUTHRELAY2 - 40839a2c) id dm21.45208a19.288cc; Mon, 2 Oct 2006 12:33:26 -0700 X-Eon-Sig: AQKyyCtFIWmGiQld1wIAAAAC,53062ae1eec4a8b97decc7a8ab115fac Message-ID: <45216982.7050309@mozilla.com> Date: Mon, 02 Oct 2006 15:33:22 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Paul Hoffman Cc: atom-syntax@imc.org Subject: Re: Atom Syndication Format To Draft Standard? References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.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: 9466e0365fc95844abaf7c3f15a05c7d Paul Hoffman wrote: > At 6:23 PM +0000 10/2/06, Robert Sayre wrote: >> That's unfortunate. A documented process is a requirement for open >> standards >> development, in the opinion of many > > If it is a true requirement, then I guess the IETF is an abysmal > failure. Oh, well. > Well, openness is only one metric. > > "needed to display" is often an issue the IETF ignores, so we might > avoid it if the desire is to get to Draft Standard. > > But Julian's second message needs to be dealt with first, and I assure > you that many of those documents are not going to be going to Draft > Standard any time soon (if ever) because there is no energy to test > every required feature in the documents. Well, I figured it might make sense to advance something that pretty much works. I now see how foolish that idea was. Cycling at proposed will be fine. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Oct 02 17:28:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVKU-0007tK-76 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 17:28:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUVKS-0005JY-MR for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 17:28:02 -0400 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 k92LATlu050380; Mon, 2 Oct 2006 14:10: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 k92LAT2O050379; Mon, 2 Oct 2006 14:10: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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92LAQcT050371 for ; Mon, 2 Oct 2006 14:10:26 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 98CDE142280; Mon, 2 Oct 2006 14:10:25 -0700 (PDT) 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 20248-08; Mon, 2 Oct 2006 14:10:25 -0700 (PDT) Received: from [10.1.1.223] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1CA77142295; Mon, 2 Oct 2006 14:10:25 -0700 (PDT) In-Reply-To: References: <4520B94C.6020209@mozilla.com> <0cf1i2p7cdalm5p8ln2os8dh7isec43oov@hive.bjoern.hoehrmann.de> <45212D7D.2000604@mozilla.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-22--1019888356 Message-Id: Cc: atom-syntax@imc.org From: Lisa Dusseault Subject: Re: Atom Syndication Format To Draft Standard? Date: Mon, 2 Oct 2006 14:10:21 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 --Apple-Mail-22--1019888356 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The Draft Standard requirement for demonstrated interoperability for all features is documented in RFC2026. It's that requirement which leads to the popular conclusion that in many cases, adding a new feature is incompatible with moving to Draft Standard at the same time -- that popular conclusion is part of the folklore, not part of the requirements, which is appropriate. You could draw a different conclusion and argue for that conclusion and might meet with some success, because determining sufficient "demonstrated interoperability" is sometimes going to be a judgement call anyway. Lisa On Oct 2, 2006, at 11:23 AM, Robert Sayre wrote: > > That's unfortunate. A documented process is a requirement for open > standards > development, in the opinion of many > > 20Definition.pdf> --Apple-Mail-22--1019888356 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

The Draft Standard = requirement for demonstrated interoperability for all features is = documented in RFC2026.=A0 It's that requirement which leads to the = popular conclusion that in many cases, adding a new feature is = incompatible with moving to Draft Standard at the same time -- that = popular conclusion is part of the folklore, not part of the = requirements, which is appropriate.=A0

You could draw a different = conclusion and argue for that conclusion and might meet with some = success, because determining sufficient "demonstrated=A0 = interoperability" is sometimes going to be a judgement call = anyway.

Lisa


On Oct 2, 2006, at = 11:23 AM, Robert Sayre wrote:


That's unfortunate. A documented process is a requirement for = open standards

development, in the opinion of many


<http://blogs.sun.com/dennisding/resource/Open%20Standard%20Defini= tion.pdf>


= --Apple-Mail-22--1019888356-- From owner-atom-syntax@mail.imc.org Mon Oct 02 19:40:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXOK-0007ps-Fy for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 19:40:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUXOJ-0001D8-3K for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 19:40:08 -0400 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 k92NKPUa070945; Mon, 2 Oct 2006 16:20: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 k92NKPqn070944; Mon, 2 Oct 2006 16:20: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92NKOqk070937 for ; Mon, 2 Oct 2006 16:20:25 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so5299nfa for ; Mon, 02 Oct 2006 16:20:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=mfBwX1Q8ewlYzvOLsfXIRVKbv5et9zkd49/7d7xumT9LiLNrYb/4l56jlLrhhg/rdup9YXZwmNpXtzwrtB/+pX9inuJS89XoA/PEK1l6XlF3CDxRRYNCsLNC7WTmma/2ipx0ONxJ6Ri1KUVKdaiMEL1CrGaM887YXytiy9KQu7s= Received: by 10.78.183.15 with SMTP id g15mr3993228huf; Mon, 02 Oct 2006 16:20:21 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 30sm5023414hue.2006.10.02.16.20.19; Mon, 02 Oct 2006 16:20:20 -0700 (PDT) Message-ID: <45219EA1.7090302@gmail.com> Date: Mon, 02 Oct 2006 16:20:01 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?) References: <4520B94C.6020209@mozilla.com> In-Reply-To: <4520B94C.6020209@mozilla.com> 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 I think the suggestion of adding a dir attribute is a very good idea. The great thing is that it can be done without any significant backwards compatibility concerns. The definition of the attribute is simple enough: atomCommonAttributes = attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }?, attribute dir { "rtl" | "ltr" }?, undefinedAttribute* The attribute establishes the base direction of the text content of an element (and plain text attributes, e.g. category/@label) and is pretty much identical in form to XHTML's dir attribute. I'm not 100% certain, but we'd likely be better off limiting the definition such that only "Language Sensitive" elements and attributes are affected by the dir attribute. In any case, +1 from me. - James Robert Sayre wrote: > > I think we should move the format to Draft Standard by clearing up any > errata and adding two attributes: 'dir' and 'unicode-bidi', as defined > in XHTML. > > Thoughts? > > Robert Sayre > > From owner-atom-syntax@mail.imc.org Mon Oct 02 21:13:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYqZ-0003wF-QH for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 21:13:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYqW-0002KC-6f for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 21:13:23 -0400 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 k930ttix086645; Mon, 2 Oct 2006 17:55: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 k930ttwD086644; Mon, 2 Oct 2006 17:55: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 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 k930trX5086527 for ; Mon, 2 Oct 2006 17:55:54 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061003005547.SHNO1865.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Tue, 3 Oct 2006 01:55:47 +0100 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20061003005547.IYZK15733.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com>; Tue, 3 Oct 2006 01:55:47 +0100 Date: Tue, 3 Oct 2006 01:55:31 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <123430939.20061003015531@djpowell.net> To: James M Snell CC: atom-syntax@imc.org Subject: Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?) In-Reply-To: <45219EA1.7090302@gmail.com> References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@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.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Tuesday, October 3, 2006, 12:20:01 AM, James Snell wrote: > I think the suggestion of adding a dir attribute is a very good idea. > The great thing is that it can be done without any significant backwards > compatibility concerns. The definition of the attribute is simple enough: > atomCommonAttributes = > attribute xml:base { atomUri }?, > attribute xml:lang { atomLanguageTag }?, > attribute dir { "rtl" | "ltr" }?, > undefinedAttribute* In the context of Atom, what's the problem with the Unicode bidi control characters? I suspect that browsers and standard OS text input widgets have better support for Unicode bidi, than they do for a currently non-existing Atom attribute. Which elements would this help? content, subtitle, summary, rights and title support HTML, so this wouldn't be necessary for them. updated, published, logo, id, and icon I would guess can cope without. extensions are responsible for their own namespace, I don't think that we need to say what attributes can appear on an extension. I think link@title, category@label, and person@name are the only attributes that would really benefit. Wouldn't Unicode bidi be more powerful than a single direction element, that would restrict the field to a single direction? As we depend on Unicode, then we can't really stop people from using Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even CSS bidi controls. I think we should think carefully before we introduce yet another method for bidi text. Especially one that will be incompatible with all existing Atom consumers. -- Dave From owner-atom-syntax@mail.imc.org Mon Oct 02 21:22:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYz2-0000vm-SJ for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 21:22:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYyy-0002ym-FH for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 21:22:08 -0400 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 k9313vA3087599; Mon, 2 Oct 2006 18:03: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 k9313vKO087598; Mon, 2 Oct 2006 18:03: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 homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9313uQ2087592 for ; Mon, 2 Oct 2006 18:03:56 -0700 (MST) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8C6344EFB3; Mon, 2 Oct 2006 21:03:52 -0400 (EDT) In-Reply-To: <45219EA1.7090302@gmail.com> References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <45021625-576E-4EE4-8CE4-C7F458A483C5@w3.org> Cc: Martin Duerst , Richard Ishida From: Karl Dubost Subject: Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?) Date: Tue, 3 Oct 2006 10:03:38 +0900 To: atom-syntax Syntax X-Mailer: Apple Mail (2.752.2) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9313vQ2087593 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 k9313vA3087599 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Le 3 oct. 06 =E0 08:20, James M Snell a =E9crit : > I think the suggestion of adding a dir attribute is a very good idea. > The great thing is that it can be done without any significant =20 > backwards > compatibility concerns. The definition of the attribute is simple =20 > enough: > > atomCommonAttributes =3D > attribute xml:base { atomUri }?, > attribute xml:lang { atomLanguageTag }?, > attribute dir { "rtl" | "ltr" }?, > undefinedAttribute* > > The attribute establishes the base direction of the text content of an > element (and plain text attributes, e.g. category/@label) and is =20 > pretty > much identical in form to XHTML's dir attribute. dir attribute in HTML. http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2 Though in Unicode 5.0 which has been just published [[[ In UAX #9, "Bidirectional Algorithm," for better interoperability, the algorithm was modified to tighten up the conformance requirements for using mirrored glyphs for characters. Higher level protocols are discouraged, due to interoperability and security considerations. The definition of directional run was changed to be the same as level run, and the use of soft-hyphen with bidi text was clarified. ]]] -- Unicode 5.0.0 http://www.unicode.org/versions/Unicode5.0.0/ Tue, 29 Aug 2006 17:33:36 GMT Maybe Martin or Richard can give us more information about it. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Mon Oct 02 21:45:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUZLE-0001kw-My for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 21:45:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUZLD-0005NF-AL for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 21:45:04 -0400 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 k931LbAl089259; Mon, 2 Oct 2006 18:21: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 k931LbYC089258; Mon, 2 Oct 2006 18:21: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 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 k931Lamh089249 for ; Mon, 2 Oct 2006 18:21:36 -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 <20061003012130.SJWQ1865.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 3 Oct 2006 02:21:30 +0100 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20061003012130.PZRO644.aamtaout01-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com> for ; Tue, 3 Oct 2006 02:21:30 +0100 Date: Tue, 3 Oct 2006 02:21:15 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <112484636.20061003022115@djpowell.net> To: atom-syntax@imc.org Subject: Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?) In-Reply-To: <123430939.20061003015531@djpowell.net> References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> <123430939.20061003015531@djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Tuesday, October 3, 2006, 1:55:31 AM, I wrote: > As we depend on Unicode, then we can't really stop people from using > Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even > CSS bidi controls. I think we should think carefully before we > introduce yet another method for bidi text. Hmm, that sounded a bit odd. I don't want to "stop people from using bidi"... I was trying to say that implementations can support Unicode bidi and HTML bidi today without any change to the spec, and that they seem more powerful than an Atom bidi attribute. -- Dave From owner-atom-syntax@mail.imc.org Mon Oct 02 22:00:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUZaA-0005K2-K6 for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 22:00:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUZa8-00063k-6F for atompub-archive@lists.ietf.org; Mon, 02 Oct 2006 22:00:30 -0400 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 k931ibHl094224; Mon, 2 Oct 2006 18:44: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 k931ibon094223; Mon, 2 Oct 2006 18:44: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 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 k931iZiH094215 for ; Mon, 2 Oct 2006 18:44:36 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so171676wxc for ; Mon, 02 Oct 2006 18:44:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=M637CHBbx152vnH2cHFTCPnKRJQbwWZh9TVlPuVOoKnRlu9OMsmSF08DP0tJFP3cyjcInfipLrzRLh8Y2JO2uU9LwhK9VbEbmC12/nDy8aMjFFWrii559B+VFNnIyy0ZINNKdfXje+V2c9LwgsH9e8AtdJzlJlXNMa44N9OJvg8= Received: by 10.70.91.11 with SMTP id o11mr7876823wxb; Mon, 02 Oct 2006 18:44:34 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 26sm8538044wra.2006.10.02.18.44.34; Mon, 02 Oct 2006 18:44:34 -0700 (PDT) Message-ID: <4521C071.6070902@gmail.com> Date: Mon, 02 Oct 2006 18:44:17 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: David Powell CC: atom-syntax@imc.org Subject: Re: Atom and bidi References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> <123430939.20061003015531@djpowell.net> <112484636.20061003022115@djpowell.net> In-Reply-To: <112484636.20061003022115@djpowell.net> 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 The challenge is not so much with (X)HTML as it is with the plain text variants of content and Text constructs and with Language-Sensitive attributes. Currently, the bidi control characters are the only way to establish the directionality in a content/@type="text" element. Of course, that works, but allowing a dir="rtl" attribute to specify a default direction in the absence of an explicit RLO/RLE and PDF in the text content makes life a bit easier for content publishers. just to be clear, I'm saying the following would be equivalent (where [RLO] and [PDF] represent the corresponding bidi controls) ABCDEFG [RLO]ABCDEFG[PDF] If the default direction for the entire document is RTL, allowing that to be established at the feed or entry element level can save some effort adding the appropriate controls to every text element. - James David Powell wrote: > > Tuesday, October 3, 2006, 1:55:31 AM, I wrote: > >> As we depend on Unicode, then we can't really stop people from using >> Unicode bidi. We can't stop people from using HTML/XHTML bidi. Or even >> CSS bidi controls. I think we should think carefully before we >> introduce yet another method for bidi text. > > Hmm, that sounded a bit odd. I don't want to "stop people from using > bidi"... > > I was trying to say that implementations can support Unicode bidi and > HTML bidi today without any change to the spec, and that they seem > more powerful than an Atom bidi attribute. > From owner-atom-syntax@mail.imc.org Tue Oct 03 02:58:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeEc-0003sC-LQ for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 02:58:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUeEY-0000lG-1e for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 02:58:34 -0400 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 k936ar25055238; Mon, 2 Oct 2006 23:36: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 k936arLq055235; Mon, 2 Oct 2006 23:36: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 scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k936ao1k055170 for ; Mon, 2 Oct 2006 23:36:51 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k936aU9j023940 for ; Tue, 3 Oct 2006 15:36:30 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4a76_80b61382_52a9_11db_9962_0014221fa3c9; Tue, 03 Oct 2006 15:36:29 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:50119) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Oct 2006 15:36:23 +0900 Message-Id: <6.0.0.20.2.20061003141916.08795630@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 Oct 2006 14:20:08 +0900 To: Julian Reschke , Paul Hoffman From: Martin Duerst Subject: Re: Atom Syndication Format To Draft Standard? Cc: Robert Sayre , atom-syntax@imc.org In-Reply-To: <45216418.9020507@gmx.de> References: <4520B94C.6020209@mozilla.com> <45216418.9020507@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 At 04:10 06/10/03, Julian Reschke wrote: >Independantly of that, what do we do with all the normative references to proposed standards...: >RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible with this document's standard level! I've definitely thought about moving that a level forward, but that may take another few months or so. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From owner-atom-syntax@mail.imc.org Tue Oct 03 04:09:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfKu-0002ec-FN for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 04:09:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfKp-0004wO-0m for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 04:09:08 -0400 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 k937sBKv068801; Tue, 3 Oct 2006 00:54: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 k937sBoi068800; Tue, 3 Oct 2006 00:54: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 pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k937s68E068743 for ; Tue, 3 Oct 2006 00:54:10 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.45.41] (210.193.203.50) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 3 Oct 2006 12:06:00 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 03 Oct 2006 12:03:50 +1000 Subject: Re: Atom and bidi From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4521C071.6070902@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: 1ac7cc0a4cd376402b85bc1961a86ac2 On 3/10/06 11:44 AM, "James M Snell" wrote: > If the default direction for the entire document is RTL, allowing that > to be established at the feed or entry element level can save some > effort adding the appropriate controls to every text element. so @dir is to be inherited by contained elements (similar to how xml:lang and xml:base is)? what happens with ? e. From owner-atom-syntax@mail.imc.org Tue Oct 03 04:09:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfKu-0002ed-FU for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 04:09:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfKp-0004wd-0m for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 04:09:08 -0400 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 k937tJT6068985; Tue, 3 Oct 2006 00:55: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 k937tJti068984; Tue, 3 Oct 2006 00:55: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 pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k937tI1d068977 for ; Tue, 3 Oct 2006 00:55:18 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.45.41] (210.193.203.50) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 3 Oct 2006 12:06:00 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 03 Oct 2006 12:03:50 +1000 Subject: Re: Atom and bidi From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4521C071.6070902@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: 1ac7cc0a4cd376402b85bc1961a86ac2 On 3/10/06 11:44 AM, "James M Snell" wrote: > If the default direction for the entire document is RTL, allowing that > to be established at the feed or entry element level can save some > effort adding the appropriate controls to every text element. so @dir is to be inherited by contained elements (similar to how xml:lang and xml:base is)? what happens with ? e. From owner-atom-syntax@mail.imc.org Tue Oct 03 04:16:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUfRn-0008HT-U1 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 04:16:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUfRe-0005mp-Ga for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 04:16:15 -0400 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 k9380fuo070861; Tue, 3 Oct 2006 01:00: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 k9380fSX070860; Tue, 3 Oct 2006 01:00: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 sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9380eoB070846 for ; Tue, 3 Oct 2006 01:00:41 -0700 (MST) (envelope-from fora@annevankesteren.nl) Received: from id-c0020 ([195.66.57.144]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k9380aJP025260; Tue, 3 Oct 2006 08:00:38 GMT To: "Eric Scheid" , "Atom Syntax" Subject: Re: Atom and bidi From: "Anne van Kesteren" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: Date: Tue, 03 Oct 2006 10:00:31 +0200 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.02 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by balder-227.proper.com id k9380foB070855 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Tue, 03 Oct 2006 04:03:50 +0200, Eric Scheid wrote: > what happens with ? The same as with ... (Please don't ask the obvious question, it's probably not defined.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Oct 03 06:46:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhn9-0000iZ-PZ for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 06:46:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhn5-00075n-49 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 06:46:27 -0400 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 k93AOoUK011493; Tue, 3 Oct 2006 03:24: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 k93AOo1g011492; Tue, 3 Oct 2006 03:24: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 mail.internode.on.net (bld-mail03.adl2.internode.on.net [203.16.214.67]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93AOjeG011420 for ; Tue, 3 Oct 2006 03:24:49 -0700 (MST) (envelope-from arsptr@internode.on.net) Received: from [192.168.1.3] (unverified [59.167.25.208]) by mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 29610498 for multiple; Tue, 03 Oct 2006 19:54:37 +0930 (CST) In-Reply-To: <45212065.3050203@metalab.unc.edu> References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-1--972234256 Message-Id: <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> Cc: James M Snell , Bill de hOra , atom-syntax@imc.org From: Alastair Rankine Subject: Re: Atom Export Date: Tue, 3 Oct 2006 20:24:35 +1000 To: Elliotte Harold X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c --Apple-Mail-1--972234256 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 03/10/2006, at 12:21 AM, Elliotte Harold wrote: > XOP, if I understand it correctly, could in fact be packaged in a > zip file, though no such packaging is described in the spec. If you > went with a non-XOP zip as opposed to XOP, I suspect you'd probably > end up reinventing a lot of XOP along the way. If you could get > away with 20% of XOP, then it might be worthwhile to do something > custom. Otherwise, I'd just go with XOP. Just to kill my own suggestion... Now that I have read the spec and thought about about it there is a good reason for *not* using XOP for the purpose of exporting content: it's simply that the resources that accompany an Atom feed -- such as images referenced within the XHTML, enclosures, etc -- do not form part of a larger XML infoset. If the resource were part of the XML of the Atom feed, you could use XOP as an alternative to base64-encoding it. But because the referenced binary objects are separate entites (in the generic non-XML sense of the word), I don't think XOP is applicable here. > Another possibility: OpenOffice does something very much like this > (zipped XML + media). Does anyone know if that format is > sufficiently generic to handle this use case? After a quick scan (http://hacks.oreilly.com/pub/h/2097) I'd say almost certainly, but it adds a lot of other stuff which may or may not be useful for Atom export. Instead, how about this: a zipfile with a single "index.xml" file containing the Atom export document (as currently proposed), with all other resources added to the zipfile according to their relative URLs from the site being exported. Say we had a blog at http://example.com which in turn referenced images at http://example.com/images/* and enclosures at http:// example.com/enclosures/*, the resulting zipfile would contain: index.xml images/1.jpg images/2.jpg ... enclosures/1.mp3 enclosures/2.mp3 ... Seems simple enough, but there's almost certainly some complexity that I'm overlooking. --Apple-Mail-1--972234256 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 03/10/2006, at = 12:21 AM, Elliotte Harold wrote:

XOP, if I understand it correctly, could in fact be = packaged in a zip file, though no such packaging is described in the = spec. If you went with a non-XOP zip as opposed to XOP, I suspect you'd = probably end up reinventing a lot of XOP along the way. If you could get = away with 20% of XOP, then it might be worthwhile to do something = custom. Otherwise, I'd just go with XOP.

Just to kill my own = suggestion... Now that I have read the spec and thought about about it = there is a good reason for *not* using XOP for the purpose of exporting = content: it's simply that the resources that accompany an Atom feed -- = such as images referenced within the XHTML, enclosures, etc -- do not = form part of a larger XML infoset. If the resource were part of the XML = of the Atom feed, you could use XOP as an alternative to base64-encoding = it. But because the referenced binary objects are separate entites (in = the generic non-XML sense of the word), I don't think XOP is applicable = here.

Another possibility: OpenOffice = does something very much like this (zipped XML + media). Does anyone = know if that format is sufficiently generic to handle this use = case?

After a quick scan (http://hacks.oreilly.com/pub/= h/2097) I'd say almost certainly, but it adds a lot of other stuff = which may or may not be useful for Atom export.

Instead, how about this: a = zipfile with a single "index.xml" file containing the Atom export = document (as currently proposed), with all other resources added to the = zipfile according to their relative URLs from the site being = exported.

Say=A0we had a blog at http://example.com which in turn = referenced images at http://example.com/images/* and = enclosures at http://example.com/enclosures/*, the resulting zipfile would contain:



= --Apple-Mail-1--972234256-- From owner-atom-syntax@mail.imc.org Tue Oct 03 08:07:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUj3J-0007MV-NP for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:07:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUj3E-0008NC-8L for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:07:13 -0400 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 k93BlEOP030167; Tue, 3 Oct 2006 04:47: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 k93BlEZV030166; Tue, 3 Oct 2006 04:47: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 bay0-omc3-s1.bay0.hotmail.com (bay0-omc3-s1.bay0.hotmail.com [65.54.246.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93BlBPs030153 for ; Tue, 3 Oct 2006 04:47:14 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.145]) by bay0-omc3-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 04:47:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Oct 2006 04:47:06 -0700 Message-ID: Received: from 81.179.103.143 by BAY120-DAV7.phx.gbl with DAV; Tue, 03 Oct 2006 11:47:01 +0000 X-Originating-IP: [81.179.103.143] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> <123430939.20061003015531@djpowell.net> <112484636.20061003022115@djpowell.net> <4521C071.6070902@gmail.com> Subject: Re: Atom and bidi Date: Tue, 3 Oct 2006 12:47:00 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 03 Oct 2006 11:47:06.0123 (UTC) FILETIME=[A6731DB0:01C6E6E1] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 James M Snell wrote: > just to be clear, I'm saying the following would be equivalent (where > [RLO] and [PDF] represent the corresponding bidi controls) > > ABCDEFG > [RLO]ABCDEFG[PDF] You should be aware that there is a significant difference between RTL override, RTL embedding and the RTL direction attribute in HTML. Regards James From owner-atom-syntax@mail.imc.org Tue Oct 03 08:20:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUjGE-0008AG-RC for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:20:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUjG6-0001Q7-EA for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:20:34 -0400 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 k93C3xYK032678; Tue, 3 Oct 2006 05:03: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 k93C3xbQ032676; Tue, 3 Oct 2006 05:03: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k93C3six032528 for ; Tue, 3 Oct 2006 05:03:57 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 Oct 2006 12:03:49 -0000 Received: from xdsl-213-196-246-158.netcologne.de (EHLO klangraum) [213.196.246.158] by mail.gmx.net (mp029) with SMTP; 03 Oct 2006 14:03:49 +0200 X-Authenticated: #163624 Date: Tue, 3 Oct 2006 14:03:47 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Atom Export Message-ID: <20061003120347.GA1618@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k93C3xYK032678 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * Alastair Rankine [2006-10-03 12:40]: > Instead, how about this: a zipfile with a single "index.xml" > file containing the Atom export document (as currently > proposed), with all other resources added to the zipfile > according to their relative URLs from the site being exported. I=E2=80=99d rather the normative URIs for the media resources be given by way of an alternate link in entries associated with each of the resources. You=E2=80=99ll want such entries anyway in order to store any associated textual data (eg. the description of an image) and preserve other metadata such as who uploaded a file. Within the zip, the file would be identified by using the atom:content/@src attribute. The zip structure could be completely free-form with the exception of the name and placement of the master feed. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Oct 03 08:25:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUjKs-0003eK-D4 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:25:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUjKq-0002VP-U8 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:25:22 -0400 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 k93C5dY3033969; Tue, 3 Oct 2006 05:05: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 k93C5dxm033966; Tue, 3 Oct 2006 05:05: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k93C5b0V033876 for ; Tue, 3 Oct 2006 05:05:37 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 Oct 2006 12:05:31 -0000 Received: from xdsl-213-196-246-158.netcologne.de (EHLO klangraum) [213.196.246.158] by mail.gmx.net (mp044) with SMTP; 03 Oct 2006 14:05:31 +0200 X-Authenticated: #163624 Date: Tue, 3 Oct 2006 14:05:30 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Atom Export Message-ID: <20061003120530.GB1618@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <20061002081241.GB2624@klangraum> <452121D8.3030509@metalab.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <452121D8.3030509@metalab.unc.edu> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k93C5dY3033969 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 * Elliotte Harold [2006-10-02 16:40]: > It would essentially rule out using DOM to process this stuff, > for example. OK, sold. I hadn=E2=80=99t thought of that. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Oct 03 08:34:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUjTc-0000zj-5U for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:34:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUjTX-00049u-Nl for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 08:34:24 -0400 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 k93CGc1U040545; Tue, 3 Oct 2006 05:16: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 k93CGcAc040544; Tue, 3 Oct 2006 05:16: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 mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93CGb1A040505 for ; Tue, 3 Oct 2006 05:16:38 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 28477 invoked from network); 3 Oct 2006 12:16:30 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 3 Oct 2006 12:16:30 -0000 Message-ID: <4522549C.7040207@metalab.unc.edu> Date: Tue, 03 Oct 2006 08:16:28 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alastair Rankine CC: James M Snell , Bill de hOra , atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> In-Reply-To: <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> 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 k93CGc1U040545 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Alastair Rankine wrote: > Seems simple enough, but there's almost certainly some complexity that=20 > I'm overlooking. Yep. What if the images aren't subdirectories of the blog. e.g. Say we had a blog at http://example.com/foo/bar/blog which in turn=20 referenced images at http://example.com/images/* and enclosures at=20 http://example.com/enclosures/*, the resulting zipfile would contain: foo/bar/blog/index.xml images/1.jpg images/2.jpg ... enclosures/1.mp3 enclosures/2.mp3 Either you need to rewrite URLs are you need one new file at a know=20 location, not present in the blog itself, to identify where the master=20 index is. Or maybe not. xml:base attributes in the index.xml might be sufficient=20 to straighten this all out. Indeed that might be necessary because=20 different blog entries live at different URLs themselves. e.g.=20 images/dog.png means one thing at http://example.com/blog/2006/Hello and=20 another at http://example.com/blog/2005/Hello Perhaps it would be helpful to back up a step. Rather than starting with=20 format design let's try to get a list of everything we need to include=20 in this format. E.g. 1. Complete source text for every blog entry. 2. Metadata for each blog entry A. Title B. Catgeory C. Tags 3. All media referenced by relative URLs from blog entry 4. URL of blog entry What else? --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai= tA/ From owner-atom-syntax@mail.imc.org Tue Oct 03 10:57:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUli2-0004Pd-S6 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 10:57:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUlhH-0002Bz-Se for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 10:56:41 -0400 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 k93EXVLf001832; Tue, 3 Oct 2006 07:33: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 k93EXVpk001831; Tue, 3 Oct 2006 07:33: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 ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93EXSI7001817 for ; Tue, 3 Oct 2006 07:33:31 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id 36so683161uga for ; Tue, 03 Oct 2006 07:33:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ao0dyCAZEMwnJNorpy1nd5Le2PizMdZxpFz5Dz9WZTOT0qhwUYgcqQB84ZY+r5lchmrW9BnxBvt/9jGkLLTmwEMt4vUWPMHJvLdrF6CH/nDLIxMGCOrjfvpA08GZ8/sB/XfkL12aeoZTuLjP/mfhLuxeKx+Lt27NgXA/TFzDLts= Received: by 10.78.165.16 with SMTP id n16mr4492226hue; Tue, 03 Oct 2006 07:33:27 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 30sm5783845hub.2006.10.03.07.33.25; Tue, 03 Oct 2006 07:33:26 -0700 (PDT) Message-ID: <452274A3.1040503@gmail.com> Date: Tue, 03 Oct 2006 07:33:07 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org Subject: Re: Atom and bidi References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> <123430939.20061003015531@djpowell.net> <112484636.20061003022115@djpowell.net> <4521C071.6070902@gmail.com> In-Reply-To: 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: 52e1467c2184c31006318542db5614d5 Doh! I actually meant [RLE] here and not [RLO]. Either way, yes, I know there is a difference. The point I was trying to make is the same made in HTML4-8.2: Although Unicode specifies special characters that deal with text direction, HTML offers higher-level markup constructs that do the same thing: the dir attribute (do not confuse with the DIR element) and the BDO element. Thus, to express a Hebrew quotation, it is more intuitive to write ...a Hebrew quotation... than the equivalent with Unicode references: ‫״...a Hebrew quotation...״‬ - James James Holderness wrote: > > James M Snell wrote: >> just to be clear, I'm saying the following would be equivalent (where >> [RLO] and [PDF] represent the corresponding bidi controls) >> >> ABCDEFG >> [RLO]ABCDEFG[PDF] > > You should be aware that there is a significant difference between RTL > override, RTL embedding and the RTL direction attribute in HTML. > > Regards > James > > From owner-atom-syntax@mail.imc.org Tue Oct 03 10:57:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUliR-00059C-5p for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 10:57:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUlXc-00018H-Kf for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 10:46:42 -0400 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 k93EU2r9001183; Tue, 3 Oct 2006 07:30: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 k93EU26n001182; Tue, 3 Oct 2006 07:30: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 sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93EU0j8001161 for ; Tue, 3 Oct 2006 07:30:01 -0700 (MST) (envelope-from fora@annevankesteren.nl) Received: from id-c0020 ([195.66.57.144]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k93ETvgS031905; Tue, 3 Oct 2006 14:29:59 GMT To: "James M Snell" , "Eric Scheid" Subject: Re: Atom and bidi From: "Anne van Kesteren" Cc: "Atom Syntax" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <452272F4.7090100@gmail.com> Date: Tue, 03 Oct 2006 16:29:57 +0200 Message-ID: In-Reply-To: <452272F4.7090100@gmail.com> User-Agent: Opera Mail/9.02 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by balder-227.proper.com id k93EU2j8001177 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, 03 Oct 2006 16:25:56 +0200, James M Snell wrote: > A dir="rtl" on the content element establishes the base direction for > the content but, just as with xml:lang, the content itself can override > the value using whatever mechanisms are native to the content type. xml:lang doesn't go to a child (embedded) document. > Eric Scheid wrote: >> On 3/10/06 11:44 AM, "James M Snell" wrote: >> >>> If the default direction for the entire document is RTL, allowing that >>> to be established at the feed or entry element level can save some >>> effort adding the appropriate controls to every text element. >> >> so @dir is to be inherited by contained elements (similar to how >> xml:lang >> and xml:base is)? >> >> what happens with ? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Oct 03 10:57:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUliS-0005BK-9Z for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 10:57:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUlXR-00017c-VW for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 10:46:31 -0400 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 k93EQKOo099589; Tue, 3 Oct 2006 07:26: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 k93EQKoS099588; Tue, 3 Oct 2006 07:26: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 ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93EQIPb099552 for ; Tue, 3 Oct 2006 07:26:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id 36so682034uga for ; Tue, 03 Oct 2006 07:26:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=StAHexLycQL+IRV5d3Rz++3dGn6yb7ONRHlto8C62Po604s2UM6uSwVVCUOC2s24jlRsELUpi96ZyDOU+shNRoOiVgfSVkoQe17EuHFdp69flPGzL5NzU6ujeMNOvlskd8M+zWOXVwZyIIxR2kH+ZrZzzFYKZr2bxYxKO33W6eQ= Received: by 10.78.160.2 with SMTP id i2mr4497446hue; Tue, 03 Oct 2006 07:26:17 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 33sm5361237hue.2006.10.03.07.26.15; Tue, 03 Oct 2006 07:26:17 -0700 (PDT) Message-ID: <452272F4.7090100@gmail.com> Date: Tue, 03 Oct 2006 07:25:56 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Atom and bidi References: In-Reply-To: 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 A dir="rtl" on the content element establishes the base direction for the content but, just as with xml:lang, the content itself can override the value using whatever mechanisms are native to the content type. - James Eric Scheid wrote: > On 3/10/06 11:44 AM, "James M Snell" wrote: > >> If the default direction for the entire document is RTL, allowing that >> to be established at the feed or entry element level can save some >> effort adding the appropriate controls to every text element. > > so @dir is to be inherited by contained elements (similar to how xml:lang > and xml:base is)? > > what happens with ? > > e. > > From owner-atom-syntax@mail.imc.org Tue Oct 03 11:31:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmEx-0002wX-CD for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 11:31:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmEu-00089l-U0 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 11:31:27 -0400 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 k93F3PXw021753; Tue, 3 Oct 2006 08:03: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 k93F3Pt8021752; Tue, 3 Oct 2006 08:03: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93F3NWs021745 for ; Tue, 3 Oct 2006 08:03:24 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so186450nfa for ; Tue, 03 Oct 2006 08:03:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=j/LSuun+yXwowxGVp8dTxUqKLxpz8/6wQYBc0l4zdiCQ62Xuv3aqQzvZW7R77T0MUUdgiag9kLlKeuo/AI48/+cTRPWXqEVgB5T6ZOudOSaEZOwf+26+z6hk1pA48YPs4e72Frzo5ZWald7UE4ZWGgvhXtK7bRmRHN+gdHEa1HM= Received: by 10.78.196.10 with SMTP id t10mr2415702huf; Tue, 03 Oct 2006 08:03:22 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 39sm5110438hug.2006.10.03.08.03.20; Tue, 03 Oct 2006 08:03:21 -0700 (PDT) Message-ID: <45227BA6.6040507@gmail.com> Date: Tue, 03 Oct 2006 08:03:02 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Anne van Kesteren CC: Eric Scheid , Atom Syntax Subject: Re: Atom and bidi References: <452272F4.7090100@gmail.com> In-Reply-To: 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: a7d6aff76b15f3f56fcb94490e1052e4 huh? REC-xml-2.12: The language specified by xml:lang applies to the element where it is specified (including the values of its attributes), and to all elements in its content unless overridden with another instance of xml:lang. - James Anne van Kesteren wrote: > On Tue, 03 Oct 2006 16:25:56 +0200, James M Snell > wrote: >> A dir="rtl" on the content element establishes the base direction for >> the content but, just as with xml:lang, the content itself can override >> the value using whatever mechanisms are native to the content type. > > xml:lang doesn't go to a child (embedded) document. > > >> Eric Scheid wrote: >>> On 3/10/06 11:44 AM, "James M Snell" wrote: >>> >>>> If the default direction for the entire document is RTL, allowing that >>>> to be established at the feed or entry element level can save some >>>> effort adding the appropriate controls to every text element. >>> >>> so @dir is to be inherited by contained elements (similar to how >>> xml:lang >>> and xml:base is)? >>> >>> what happens with ? > > > --Anne van Kesteren > > > > From owner-atom-syntax@mail.imc.org Tue Oct 03 11:31:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmFB-0003AS-Ru for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 11:31:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmF8-0008BR-9z for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 11:31:41 -0400 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 k93Ewqtn020765; Tue, 3 Oct 2006 07:58: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 k93EwqqB020764; Tue, 3 Oct 2006 07:58: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 bay0-omc3-s37.bay0.hotmail.com (bay0-omc3-s37.bay0.hotmail.com [65.54.246.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93EwpmH020683 for ; Tue, 3 Oct 2006 07:58:51 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.149]) by bay0-omc3-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 07:58:45 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Oct 2006 07:58:45 -0700 Message-ID: Received: from 81.179.103.143 by BAY120-DAV11.phx.gbl with DAV; Tue, 03 Oct 2006 14:58:41 +0000 X-Originating-IP: [81.179.103.143] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> <123430939.20061003015531@djpowell.net> <112484636.20061003022115@djpowell.net> <4521C071.6070902@gmail.com> <452274A3.1040503@gmail.com> Subject: Re: Atom and bidi Date: Tue, 3 Oct 2006 15:58:40 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 03 Oct 2006 14:58:45.0359 (UTC) FILETIME=[6C8747F0:01C6E6FC] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 James M Snell wrote: > Doh! I actually meant [RLE] here and not [RLO]. Either way, yes, I know > there is a difference. Ok, but I think you need to clarify what exactly it is that this attribute is supposed to mean then. Because if it's just the equivalent of wrapping the content in [RLE]...[PDF] it's essentially useless. If it's the equivalent of wrapping the content in
...
then I can see some value. Regards James From owner-atom-syntax@mail.imc.org Tue Oct 03 11:33:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmH3-000509-PD for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 11:33:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmH2-00007G-CT for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 11:33:37 -0400 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 k93FDvmh024171; Tue, 3 Oct 2006 08:13: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 k93FDvYS024167; Tue, 3 Oct 2006 08:13: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 sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93FDtoQ024153 for ; Tue, 3 Oct 2006 08:13:55 -0700 (MST) (envelope-from fora@annevankesteren.nl) Received: from id-c0020 ([195.66.57.144]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k93FDqJM032642; Tue, 3 Oct 2006 15:13:53 GMT Date: Tue, 03 Oct 2006 17:13:51 +0200 To: "James M Snell" Subject: Re: Atom and bidi From: "Anne van Kesteren" Cc: "Atom Syntax" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <452272F4.7090100@gmail.com> <45227BA6.6040507@gmail.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <45227BA6.6040507@gmail.com> User-Agent: Opera Mail/9.02 (Win32) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Tue, 03 Oct 2006 17:03:02 +0200, James M Snell wrote: > huh? > > REC-xml-2.12: > > The language specified by xml:lang applies to the element where > it is specified (including the values of its attributes), and to all > elements in its content unless overridden with another instance of > xml:lang. Your point being? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Oct 03 12:07:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmnV-00039z-Ks for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 12:07:09 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmnU-0006Id-7Y for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 12:07:09 -0400 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 k93FgVn9036155; Tue, 3 Oct 2006 08: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 k93FgVWK036154; Tue, 3 Oct 2006 08: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 mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93FgU08036108 for ; Tue, 3 Oct 2006 08:42:30 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mozilla.com (Postfix) with ESMTP id D99301188011; Tue, 3 Oct 2006 08:42:22 -0700 (PDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 3 08:42:22 2006 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 452284de74841410093335 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] Received: from mail.mozilla.com ([127.0.0.1]) by localhost (mail.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MEm8s03ttA3; Tue, 3 Oct 2006 08:42:22 -0700 (PDT) Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id 7CF511188002; Tue, 3 Oct 2006 08:42:22 -0700 (PDT) Message-ID: <8753636.14301159890142487.JavaMail.root@cm-mail02.mozilla.org> Date: Tue, 3 Oct 2006 08:42:22 -0700 (PDT) From: Robert Sayre To: Eric Scheid Subject: Re: Atom and bidi Cc: atom-syntax@imc.org In-Reply-To: MIME-Version: 1.0 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: 7bac9cb154eb5790ae3b2913587a40de Eric Scheid wrote: > > what happens with ? Nothing. -Rob From owner-atom-syntax@mail.imc.org Tue Oct 03 12:09:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmpb-000403-Sq for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 12:09:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmpa-0006dj-EP for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 12:09:19 -0400 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 k93FiCtb036606; Tue, 3 Oct 2006 08:44: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 k93FiCUU036605; Tue, 3 Oct 2006 08:44: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.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93FiBfI036547 for ; Tue, 3 Oct 2006 08:44:11 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mozilla.com (Postfix) with ESMTP id 854AE1188010; Tue, 3 Oct 2006 08:44:06 -0700 (PDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Oct 3 08:44:05 2006 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 45228545134287516987557 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, DSPAM_HAM=-0.1] Received: from mail.mozilla.com ([127.0.0.1]) by localhost (mail.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dYTr83q-UMG; Tue, 3 Oct 2006 08:44:05 -0700 (PDT) Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id 67A6B1188002; Tue, 3 Oct 2006 08:44:05 -0700 (PDT) Message-ID: <18620855.14331159890245385.JavaMail.root@cm-mail02.mozilla.org> Date: Tue, 3 Oct 2006 08:44:05 -0700 (PDT) From: Robert Sayre To: James Holderness Subject: Re: Atom and bidi Cc: atom-syntax@imc.org In-Reply-To: MIME-Version: 1.0 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 James Holderness wrote: >James M Snell wrote: >> Doh! I actually meant [RLE] here and not [RLO]. Either way, yes, I know >> there is a difference. > > Ok, but I think you need to clarify what exactly it is that this attribute > is supposed to mean then. I'll take that action. -Rob From owner-atom-syntax@mail.imc.org Tue Oct 03 12:17:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmxI-000167-7P for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 12:17:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmxG-0008HC-Pl for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 12:17:16 -0400 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 k93G1rsU040919; Tue, 3 Oct 2006 09:01: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 k93G1r2j040916; Tue, 3 Oct 2006 09:01: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93G1pBj040868 for ; Tue, 3 Oct 2006 09:01:52 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so201647nfa for ; Tue, 03 Oct 2006 09:01:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=c3a8r5mdEklBFD25IuQUDxyYw/JrnoQB+rkRnk3FfUhfYgMinq1LnWUq8pDtgmRv9rDAG5KafhYRNQoo/w2zIQWqa8mrFQMP1kNYBden53u4j+gkkxTS+3ELvKnMXgVjXMgN4BcJft/9YPGJeNL5z+JB08aVAW08u9zY6290Yqc= Received: by 10.49.55.13 with SMTP id h13mr993533nfk; Tue, 03 Oct 2006 09:01:49 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g9sm1435685wra.2006.10.03.09.01.48; Tue, 03 Oct 2006 09:01:48 -0700 (PDT) Message-ID: <45228959.5020607@gmail.com> Date: Tue, 03 Oct 2006 09:01:29 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Atom and bidi References: <4520B94C.6020209@mozilla.com> <45219EA1.7090302@gmail.com> <123430939.20061003015531@djpowell.net> <112484636.20061003022115@djpowell.net> <4521C071.6070902@gmail.com> <452274A3.1040503@gmail.com> In-Reply-To: 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 Yes, equivalent to
- James James Holderness wrote: > > James M Snell wrote: >> Doh! I actually meant [RLE] here and not [RLO]. Either way, yes, I know >> there is a difference. > > Ok, but I think you need to clarify what exactly it is that this > attribute is supposed to mean then. Because if it's just the equivalent > of wrapping the content in [RLE]...[PDF] it's essentially useless. If > it's the equivalent of wrapping the content in
...
> then I can see some value. > > Regards > James > > From owner-atom-syntax@mail.imc.org Tue Oct 03 13:34:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUoAS-00020d-MD for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 13:34:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUoAJ-0000V5-A6 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 13:34:56 -0400 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 k93HGifx064552; Tue, 3 Oct 2006 10:16: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 k93HGiRr064551; Tue, 3 Oct 2006 10:16: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 ironclad.com.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93HGgZO064483 for ; Tue, 3 Oct 2006 10:16:43 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by ironclad.com.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 4 Oct 2006 03:18:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 04 Oct 2006 03:14:59 +1000 Subject: Re: Atom and bidi From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <45227BA6.6040507@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: 79899194edc4f33a41f49410777972f8 On 4/10/06 1:03 AM, "James M Snell" wrote: >>> A dir="rtl" on the content element establishes the base direction for >>> the content but, just as with xml:lang, the content itself can override >>> the value using whatever mechanisms are native to the content type. >> >> xml:lang doesn't go to a child (embedded) document. > The language specified by xml:lang applies to the element where > it is specified (including the values of its attributes), and to all > elements in its content unless overridden with another instance of > xml:lang. what happens here? .. yadda .. e. From owner-atom-syntax@mail.imc.org Tue Oct 03 14:01:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUoZr-0002ll-SH for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 14:01:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUoXt-0003qb-D8 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 13:59:10 -0400 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 k93HiTO6070754; Tue, 3 Oct 2006 10:44: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 k93HiTf9070753; Tue, 3 Oct 2006 10:44: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93HiSxV070746 for ; Tue, 3 Oct 2006 10:44:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so406074wxc for ; Tue, 03 Oct 2006 10:44:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=m3swhV7W/eY4SphfeP8E8xlHGRJ0ji3kmL3TGvHGyoBMkjdm0WgEVrQi61IQwNd17lOXryMAWkkmTuZqi3wrookkeD31JUqC0ZOV2lKLetxEz66nEd9fRzYzIf75j6B8MerThPsNTJIYahu0WC4NNn4S5TSGwhZ50U6oJzNIJY8= Received: by 10.90.113.20 with SMTP id l20mr677270agc; Tue, 03 Oct 2006 10:44:28 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g9sm1633220wra.2006.10.03.10.44.26; Tue, 03 Oct 2006 10:44:27 -0700 (PDT) Message-ID: <4522A168.7020205@gmail.com> Date: Tue, 03 Oct 2006 10:44:08 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Atom and bidi References: In-Reply-To: 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 If I specify something like:
This is some left-to-right text with a right-to-left link
The behavior depends a large part on how the content is displayed. Typically, I would expect the above to be equivalent to:
This is some left-to-right text with a right-to-left link
However, in other contexts, depending on how the content is displayed, it could be equivalent to something like This is some left-to-right text with a right-to-left link Or even just ‎This is some left-to-right text with a right-to-left link‎ Either way, the behavior of the dir on the anchor is unmodified and standard (X)HTML rules apply. - James Eric Scheid wrote: > On 4/10/06 1:03 AM, "James M Snell" wrote: > >>>> A dir="rtl" on the content element establishes the base direction for >>>> the content but, just as with xml:lang, the content itself can override >>>> the value using whatever mechanisms are native to the content type. >>> xml:lang doesn't go to a child (embedded) document. > >> The language specified by xml:lang applies to the element where >> it is specified (including the values of its attributes), and to all >> elements in its content unless overridden with another instance of >> xml:lang. > > what happens here? > > .. yadda .. > > e. > > From owner-atom-syntax@mail.imc.org Tue Oct 03 14:51:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpMP-0005aY-NM for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 14:51:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpMO-00051H-7m for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 14:51:21 -0400 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 k93IYF6W082852; Tue, 3 Oct 2006 11:34: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 k93IYFTx082851; Tue, 3 Oct 2006 11:34: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 ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k93IYDGj082842 for ; Tue, 3 Oct 2006 11:34:14 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] ([203.30.247.118] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0005969905 for ; Wed, 04 Oct 2006 04:34:11 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 04 Oct 2006 04:34:10 +1000 Subject: Re: Atom and bidi From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4522A168.7020205@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: de4f315c9369b71d7dd5909b42224370 On 4/10/06 3:44 AM, "James M Snell" wrote: > Either way, the behavior of the dir on the anchor is unmodified and > standard (X)HTML rules apply. so how might you code this:

here is some ltr text, with a link with rtl-text which links to a document which is ltr-text

I know the difference between @xml:lang and @hreflang ... so which is @dir analogous to? e. From owner-atom-syntax@mail.imc.org Tue Oct 03 15:12:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUphA-0002UT-TW for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 15:12:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUph9-0007gR-H3 for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 15:12:48 -0400 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 k93IvmfW089004; Tue, 3 Oct 2006 11:57: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 k93IvmE6089003; Tue, 3 Oct 2006 11:57: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 ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93IvksT088997 for ; Tue, 3 Oct 2006 11:57:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id 36so734751uga for ; Tue, 03 Oct 2006 11:57:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=P9mm609XT0vSYnYXC0qBMyYWrcoORr9YHCR7CrTcLG2a6HjlVMLmnHiLmRfpcGJ1DpO+OqWQ2FTsWIs6A5uOh/LjZBA4PfBiY8h2zVCO2+h3RF3W34+vWhxQNsZO51FyllOwlzPYzw5V5RjN1+OF8elUlydACfbi1Tva5miCHAQ= Received: by 10.78.149.13 with SMTP id w13mr4856056hud; Tue, 03 Oct 2006 11:57:45 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 33sm5705888hue.2006.10.03.11.57.44; Tue, 03 Oct 2006 11:57:45 -0700 (PDT) Message-ID: <4522B295.3090704@gmail.com> Date: Tue, 03 Oct 2006 11:57:25 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Atom and bidi References: In-Reply-To: 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: 9182cfff02fae4f1b6e9349e01d62f32 Nothing, there is no hreflang analog for dir, nor is there any pressing need for such. - James Eric Scheid wrote: > On 4/10/06 3:44 AM, "James M Snell" wrote: > >> Either way, the behavior of the dir on the anchor is unmodified and >> standard (X)HTML rules apply. > > so how might you code this: > >

here is some ltr text, with a link with > rtl-text which links to a > document which is ltr-text

> > I know the difference between @xml:lang and @hreflang ... so which is @dir > analogous to? > > e. > > From owner-atom-syntax@mail.imc.org Tue Oct 03 16:03:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqUB-0006in-LP for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 16:03:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUqUA-0001mw-AP for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 16:03:27 -0400 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 k93Jm9UY098966; Tue, 3 Oct 2006 12:48: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 k93Jm9m9098962; Tue, 3 Oct 2006 12:48: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 [10.20.30.183] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93Jm7Sf098923 for ; Tue, 3 Oct 2006 12:48:08 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4522B295.3090704@gmail.com> References: <4522B295.3090704@gmail.com> Date: Tue, 3 Oct 2006 12:48:06 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: Atom and bidi 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 This is sounding, smelling, and tasting like a rathole. Having fought the bidi wars in IDN, this doesn't surprise me. It's terribly difficult, and we don't have any good examples of formats or protocols that have gotten it right in a clean fashion. That's not to say we can't do it, just that we need to see a proposal with all the wording before we decide if it is right. From owner-atom-syntax@mail.imc.org Tue Oct 03 19:17:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUtWN-00087h-ML for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 19:17:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUtWM-0000D7-9M for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 19:17:55 -0400 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 k93Mv8rv032845; Tue, 3 Oct 2006 15:57: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 k93Mv8Oi032844; Tue, 3 Oct 2006 15:57: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93Mv7bX032828 for ; Tue, 3 Oct 2006 15:57:08 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (83-70-239-30.b-ras1.prp.dublin.eircom.net [83.70.239.30]) by chilco.textdrive.com (Postfix) with ESMTP id 9ABD8DB9E9 for ; Tue, 3 Oct 2006 22:57:01 +0000 (UTC) Message-ID: <4522EABA.4000009@dehora.net> Date: Tue, 03 Oct 2006 23:56:58 +0100 From: Bill de hOra User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?] References: <4520B94C.6020209@mozilla.com> In-Reply-To: <4520B94C.6020209@mozilla.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: 52e1467c2184c31006318542db5614d5 Robert Sayre wrote: > > I think we should move the format to Draft Standard by clearing up any > errata and adding two attributes: 'dir' and 'unicode-bidi', as defined > in XHTML. > > Thoughts? "Foreign markup" is ambiguous. [[[ Markup from other vocabularies ("foreign markup") can be used in an Atom Document. ]]] [[[ For the purposes of this discussion, unrecognized markup from the Atom vocabulary will be considered "foreign markup". ]]] Perhaps this is what's intended by those statements: """ Markup not defined in this document is called "foreign markup" """ I don't think the document can forward to proposed without clarification. Also, "forward-compatible" is mentioned, but not defined - it's not possible to make a safe assumption on what it means, since it's relative to whatever "foreign markup" is. I assume "unrecognized" and "unknown" are synonymous. cheers Bill From owner-atom-syntax@mail.imc.org Tue Oct 03 20:22:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuWY-0000GX-4e for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 20:22:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUuWV-0002x9-Nz for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 20:22:10 -0400 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 k93NrWFS044538; Tue, 3 Oct 2006 16:53: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 k93NrWhu044537; Tue, 3 Oct 2006 16:53: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93NrVl6044525 for ; Tue, 3 Oct 2006 16:53:32 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.0.3] (user-10876hc.cable.mindspring.com [64.131.154.44]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 513FC6A8791; Tue, 3 Oct 2006 16:53:26 -0700 (PDT) Message-ID: <4522F932.8030806@mozilla.com> Date: Tue, 03 Oct 2006 19:58:42 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax@imc.org Subject: Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?] References: <4520B94C.6020209@mozilla.com> <4522EABA.4000009@dehora.net> In-Reply-To: <4522EABA.4000009@dehora.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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Bill de hOra wrote: > I don't think the document can forward to proposed without > clarification. Also, "forward-compatible" is mentioned, but not > defined - it's not possible to make a safe assumption on what it > means, since it's relative to whatever "foreign markup" is. I assume > "unrecognized" and "unknown" are synonymous. None of these seem pressing to me. I agree that it's muddy, but I haven't seen any interoperability problems result. Have you? -Rob From owner-atom-syntax@mail.imc.org Tue Oct 03 21:18:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUvPM-0004O1-Hj for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 21:18:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUvPD-0004yV-3B for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 21:18:48 -0400 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 k940xD2O057652; Tue, 3 Oct 2006 17:59: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 k940xD5J057651; Tue, 3 Oct 2006 17:59: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k940x9YI057634 for ; Tue, 3 Oct 2006 17:59:11 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 Oct 2006 00:59:03 -0000 Received: from xdsl-81-173-226-248.netcologne.de (EHLO klangraum) [81.173.226.248] by mail.gmx.net (mp013) with SMTP; 04 Oct 2006 02:59:03 +0200 X-Authenticated: #163624 Date: Wed, 4 Oct 2006 02:59:02 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?] Message-ID: <20061004005902.GM1618@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4520B94C.6020209@mozilla.com> <4522EABA.4000009@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4522EABA.4000009@dehora.net> User-Agent: Mutt/1.4.2.1i Organization: haphazard X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 * Bill de hOra [2006-10-04 01:15]: > Perhaps this is what's intended by those statements: > > """ > Markup not defined in this document is called "foreign markup" > """ No, I seem to remember pretty clearly from discussion that what it means is thus: Markup not known to the consumer is called "foreign markup" That is, extension markup the consumer knows to interpret is not foreign markup. In contradistinction, Atom markup that the consumer does not know to interpret *is* foreign markup (eg. attributes from a hypothetical future version of Atom). The document then sets forth how foreign markup should be interpreted, ie. basically what the consumer should do on finding things in a feed that it doesn't understand. > I don't think the document can forward to proposed without > clarification. Also, "forward-compatible" is mentioned, but not > defined - it's not possible to make a safe assumption on what > it means, since it's relative to whatever "foreign markup" is. > I assume "unrecognized" and "unknown" are synonymous. I think given the above background you'll agree that the intent of the document is pretty coherent. A clarification that makes this background explicit would undoubtedly be helpful, though. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Oct 03 21:57:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUw0V-0002Wc-MY for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 21:57:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUw0R-0003lO-6f for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 21:57:11 -0400 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 k941ebiQ067099; Tue, 3 Oct 2006 18:40: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 k941ebsH067098; Tue, 3 Oct 2006 18:40: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k941eaZB067083 for ; Tue, 3 Oct 2006 18:40:37 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.239.30]) by chilco.textdrive.com (Postfix) with ESMTP id E23D0DBB6D for ; Wed, 4 Oct 2006 01:40:30 +0000 (UTC) Message-ID: <4523110A.6020202@dehora.net> Date: Wed, 04 Oct 2006 02:40:26 +0100 From: Bill de hOra User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?] References: <4520B94C.6020209@mozilla.com> <4522EABA.4000009@dehora.net> <20061004005902.GM1618@klangraum> In-Reply-To: <20061004005902.GM1618@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: 1ac7cc0a4cd376402b85bc1961a86ac2 A. Pagaltzis wrote: > I think given the above background you'll agree that the intent > of the document is pretty coherent. I couldn't tell whether new Atom extensions are foreign markup, or something else to be dealt with under wrt being a "forward-compatible" friendly consumer. It's kind of circular. In short, I guessed and you told me I was wrong. cheers Bill From owner-atom-syntax@mail.imc.org Tue Oct 03 22:23:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwQP-0001nl-FL for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 22:23:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwQN-0006YR-2T for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 22:23:57 -0400 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 k9425n09075040; Tue, 3 Oct 2006 19:05: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 k9425nqj075034; Tue, 3 Oct 2006 19:05: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9425mg4075010 for ; Tue, 3 Oct 2006 19:05:48 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.1.100] (user-12ld2ss.cable.mindspring.com [69.86.139.156]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 812076A8791; Tue, 3 Oct 2006 19:05:42 -0700 (PDT) Message-ID: <452316EE.90500@mozilla.com> Date: Tue, 03 Oct 2006 22:05:34 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Bill de hOra CC: atom-syntax@imc.org Subject: Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?] References: <4520B94C.6020209@mozilla.com> <4522EABA.4000009@dehora.net> <20061004005902.GM1618@klangraum> <4523110A.6020202@dehora.net> In-Reply-To: <4523110A.6020202@dehora.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: d6b246023072368de71562c0ab503126 Bill de hOra wrote: > > A. Pagaltzis wrote: > >> I think given the above background you'll agree that the intent >> of the document is pretty coherent. > > I couldn't tell whether new Atom extensions are foreign markup, or > something else to be dealt with under wrt being a "forward-compatible" > friendly consumer. It's kind of circular. In short, I guessed and you > told me I was wrong. Bill, please show us a bug? I don't think defining terms until we've got a good subset of an English dictionary will make the format more interoperable. -Rob From owner-atom-syntax@mail.imc.org Tue Oct 03 22:48:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwo6-0002Mm-MX for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 22:48:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwo5-0001DE-9b for atompub-archive@lists.ietf.org; Tue, 03 Oct 2006 22:48:26 -0400 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 k942ZPXJ081485; Tue, 3 Oct 2006 19:35: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 k942ZPSu081484; Tue, 3 Oct 2006 19:35: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 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 k942ZOx1081467 for ; Tue, 3 Oct 2006 19:35:25 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so29182wxc for ; Tue, 03 Oct 2006 19:35:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rZljY3u0ut9O4O9ardTWKKegFvHcfdnBrFUceCtaUzRQ0kRva+mJEXrRuOg3FrzP+5DCUh8NuErlWaa0sc04f9YHyoPLNEUzm3UBURWFDRQetTKgzOvinlYjbBwaqok7oEHcQ/qEZOOb4I31IPx2HwAEJuDFofsheSqx6BA99V8= Received: by 10.70.57.2 with SMTP id f2mr89939wxa; Tue, 03 Oct 2006 19:35:21 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g9sm182696wra.2006.10.03.19.35.21; Tue, 03 Oct 2006 19:35:21 -0700 (PDT) Message-ID: <45231DE6.6040409@gmail.com> Date: Tue, 03 Oct 2006 19:35:18 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Paul Hoffman CC: Atom Syntax Subject: Re: Atom and bidi References: <4522B295.3090704@gmail.com> In-Reply-To: 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: cf4fa59384e76e63313391b70cd0dd25 Yep, I'll work up a pace. - James Paul Hoffman wrote: > > This is sounding, smelling, and tasting like a rathole. Having fought > the bidi wars in IDN, this doesn't surprise me. It's terribly difficult, > and we don't have any good examples of formats or protocols that have > gotten it right in a clean fashion. That's not to say we can't do it, > just that we need to see a proposal with all the wording before we > decide if it is right. > > From owner-atom-syntax@mail.imc.org Wed Oct 04 00:06:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUy1e-0004It-0N for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 00:06:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUy1c-0006hP-Gv for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 00:06:29 -0400 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 k943XOxc097821; Tue, 3 Oct 2006 20:33: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 k943XOMv097820; Tue, 3 Oct 2006 20:33: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 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 k943XNhL097814 for ; Tue, 3 Oct 2006 20:33:24 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so43896wxc for ; Tue, 03 Oct 2006 20:33:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=V3g8zZGToANhACmHwsg7Egb10+P5XMOtFeAtXWDUTYuhH5Ft87Nt/Ng8qWlbVuDQ7BYHFd35S85wJOJzcehXp/bgfLxZdLF9s8u30yb2qrcRrsModQuAg2aj6kNyNdCsOzxRy8vk680sT1ZZIZzgdl8MKsK0TVrBuJNq7ko5nYY= Received: by 10.70.83.8 with SMTP id g8mr226105wxb; Tue, 03 Oct 2006 20:33:22 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 12sm59423wrl.2006.10.03.20.33.22; Tue, 03 Oct 2006 20:33:22 -0700 (PDT) Message-ID: <45232B7F.2060504@gmail.com> Date: Tue, 03 Oct 2006 20:33:19 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax Subject: PaceAtomBidi 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: 3a4bc66230659131057bb68ed51598f8 This ought to give us something concrete to work from. - James #pragma section-numbers off == Abstract == RFC4287 currently has no *efficient* means of indicating the base directionality of text. While the Unicode bidi control characters can be used, they can be problematic to use correctly within XML and do not allow publishers to set a single default direction for a complete Atom document. This proposal adds a new common attribute to all Atom elements called "dir". The attribute is optional and has three possible values, "ltr", "rtl" and "" (representing 'unspecified'). If the attribute is missing, the value is considered to be unspecified. This should make the element fully backwards compatible with existing compliant RFC4287 implementations that properly handle "unknown markup". This proposal does add the requirement that bidi text in atom docs MUST be rendered using the unicode bidi algorithm but makes it clear that the use of dir on an element does not necessarily open a new level of embedding... meaning that feed consumers have the responsibility of determining how to apply the bidi algorithm based on how those consumers choose to display the text (e.g. some readers may display entry content in a
while others may display content in a , both of which handle bidi text differently depending on context). I also specify that bidi text in (x)html should use the bidi markup as defined by those specs. == Status == Proposed. == Rationale == (see abstract) == Proposal == {{{ 2.0 Add "dir" to atomCommonAttributes atomCommonAttributes = attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }?, attribute dir { "ltr" | "rtl" | "" }?, undefinedAttribute* 2.1 The "dir" Attribute Any element defined by this specification MAY have a "dir" attribute whose content specifies the base direction of directionally-neutral text [UNICODE]. Possible values for the attribute are "ltr" and "rtl" indicating "left-to-right" and "right-to-left" respectively or an empty string "" indicating that no base-direction is unspecified. If the"dir" attribute is not specified, the value is assumed to be unspecified. The direction specified by "dir" applies only to elements and attributes whose values are specified as being "Language-Sensitive". The attribute is inherited by descendent elements and may be overridden. Example atom:feed with right-to-left directionality ٹٺٻ ... If an Atom document contains any right-to-left characters, the Unicode Bidirectional Algorithm [UAX#9] MUST be used to render that text. Because consumers of Atom documents vary broadly in the way they display text, the use of the "dir" attribute on an element does not necessarily open an additional level of embedding with respect to the bidirectional algorithm. Consuming applications that render bidirectional text are responsible for determining the appropriate level of embedding. When Atom Text Constructs or the atom:content elements contain bidirectional text and the type attribute is set to either "html" or "xhtml", the bidirectional markup mechanisms specific to each format SHOULD be used. Example atom:feed with bidirectional XHTML <div xmlns="http://www.w3.org/1999/xhtml"> <p dir="rtl">ٹٺٻ</p> </div> ... The Unicode bidirectional control characters MAY also be used within attributes and element values to indicate the directionality of text. IRI's containing bidirectional characters MUST be stored, transmitted and rendered as defined in [RFC3987] Section 4. }}} == Impacts == == Notes == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Wed Oct 04 00:06:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUy1e-0004J6-Ud for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 00:06:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUy1c-0006hM-Gv for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 00:06:30 -0400 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 k943gtNS098650; Tue, 3 Oct 2006 20:42: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 k943gtjo098649; Tue, 3 Oct 2006 20:42: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k943gspv098630; Tue, 3 Oct 2006 20:42:54 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.1.100] (user-12ld2ss.cable.mindspring.com [69.86.139.156]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 207026A862F; Tue, 3 Oct 2006 20:42:47 -0700 (PDT) Message-ID: <45232DB3.1090706@mozilla.com> Date: Tue, 03 Oct 2006 23:42:43 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James M Snell CC: Paul Hoffman , Atom Syntax Subject: Re: Atom and bidi References: <4522B295.3090704@gmail.com> <45231DE6.6040409@gmail.com> In-Reply-To: <45231DE6.6040409@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: 68c8cc8a64a9d0402e43b8eee9fc4199 James M Snell wrote: > Yep, I'll work up a pace. I find this more than a little pushy. I found the problem, I think I have an answer, I've already written the code, and I said I would deal with it earlier today: -Rob From owner-atom-syntax@mail.imc.org Wed Oct 04 00:15:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyAb-000262-9E for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 00:15:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUyAZ-000803-Rn for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 00:15:45 -0400 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 k9440WVg004764; Tue, 3 Oct 2006 21:00: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 k9440WXf004763; Tue, 3 Oct 2006 21:00: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9440VxQ004748 for ; Tue, 3 Oct 2006 21:00:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so50141wxc for ; Tue, 03 Oct 2006 21:00:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OAkjafMz8ovrJyTADPIrK7zJ9gmfhxBjJred2d72cTKkkF6aT0LEVrkYUXcJh99jtMfOIRcQI3a5JyYLY4icSKFRBlCTJu+DXoWE5I3mY6RVqRhHu3BB+UVPyc0GJAnBRfXzENkbRaCBCETcD484w4hfMPrtdCXwT8iNHWebclk= Received: by 10.70.19.2 with SMTP id 2mr216946wxs; Tue, 03 Oct 2006 21:00:31 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 29sm95659wrl.2006.10.03.21.00.30; Tue, 03 Oct 2006 21:00:31 -0700 (PDT) Message-ID: <452331DC.5030002@gmail.com> Date: Tue, 03 Oct 2006 21:00:28 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 CC: Atom Syntax Subject: Re: Atom and bidi References: <4522B295.3090704@gmail.com> <45231DE6.6040409@gmail.com> <45232DB3.1090706@mozilla.com> In-Reply-To: <45232DB3.1090706@mozilla.com> 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Robert Sayre wrote: > James M Snell wrote: >> Yep, I'll work up a pace. > I find this more than a little pushy. > Cool! > I found the problem, I think I have an answer, I've already written the > code, and I said I would deal with it earlier today: > Then write up a pace. We can compare the two options and figure out the best way to move forward. Where's your code and how does it work? - James > > > -Rob > From owner-atom-syntax@mail.imc.org Wed Oct 04 01:04:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyvR-0008Oo-29 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 01:04:09 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUyvO-00027v-Lh for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 01:04:09 -0400 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 k944ihWW020159; Tue, 3 Oct 2006 21:44: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 k944ih4l020155; Tue, 3 Oct 2006 21:44: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k944igx2019975 for ; Tue, 3 Oct 2006 21:44:42 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.1.100] (user-12ld2ss.cable.mindspring.com [69.86.139.156]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 9AEFD6A8791; Tue, 3 Oct 2006 21:44:32 -0700 (PDT) Message-ID: <45233C2D.8010602@mozilla.com> Date: Wed, 04 Oct 2006 00:44:29 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James M Snell CC: Atom Syntax Subject: Re: Atom and bidi References: <4522B295.3090704@gmail.com> <45231DE6.6040409@gmail.com> <45232DB3.1090706@mozilla.com> <452331DC.5030002@gmail.com> In-Reply-To: <452331DC.5030002@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: 93238566e09e6e262849b4f805833007 James M Snell wrote: > Robert Sayre wrote: > >> James M Snell wrote: >> >>> Yep, I'll work up a pace. >>> >> I find this more than a little pushy. >> >> > > Cool! > ??? > Then write up a pace. We can compare the two options and figure out the > best way to move forward. I am not sure what you are talking about. -Rob From owner-atom-syntax@mail.imc.org Wed Oct 04 01:27:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzHl-0007NF-M1 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 01:27:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUzHk-0008LZ-AD for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 01:27:13 -0400 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 k945C9C1024879; Tue, 3 Oct 2006 22:12: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 k945C9N8024878; Tue, 3 Oct 2006 22:12: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 py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k945C8CB024872 for ; Tue, 3 Oct 2006 22:12:09 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so81060pye for ; Tue, 03 Oct 2006 22:12:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Zdt2G8Y+V0t5GYbgAAN/0suDIzaFpWRY1LQItfOqcgAkpzGL8Nra2MUffM3Z9u7WhokVXJJeyd/pKXJ7EME7eEYKuljvG54LtOKjCtUKCUzPSypAUHpwnjKSPQ7DYQewxNB5xV2CFusSod04TSGc50U/atPauwNZui0e25zlD9A= Received: by 10.65.139.9 with SMTP id r9mr294575qbn; Tue, 03 Oct 2006 22:12:08 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id e15sm281866qba.2006.10.03.22.12.07; Tue, 03 Oct 2006 22:12:08 -0700 (PDT) Message-ID: <452342A5.20609@gmail.com> Date: Tue, 03 Oct 2006 22:12:05 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Atom and bidi References: <4522B295.3090704@gmail.com> <45231DE6.6040409@gmail.com> <45232DB3.1090706@mozilla.com> <452331DC.5030002@gmail.com> <45233C2D.8010602@mozilla.com> In-Reply-To: <45233C2D.8010602@mozilla.com> 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: 79899194edc4f33a41f49410777972f8 Robert Sayre wrote: > [snip] >> Then write up a pace. We can compare the two options and figure out the >> best way to move forward. > > I am not sure what you are talking about. > You said: "I think I have an answer, I've already written the code, and I said I would deal with it earlier today" If that's the case, it would be great if you would provide a concrete proposal that we can discuss or at least describe exactly what you're looking for. As Paul mentioned, this area is way too complicated to not be talking in terms of concrete spec text. - James From owner-atom-syntax@mail.imc.org Wed Oct 04 01:47:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzbb-0004EE-2J for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 01:47:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUzbV-0001zx-M2 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 01:47:43 -0400 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 k945WccW028260; Tue, 3 Oct 2006 22:32: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 k945WcXW028259; Tue, 3 Oct 2006 22:32: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k945WcsI028240 for ; Tue, 3 Oct 2006 22:32:38 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.1.100] (user-12ld2ss.cable.mindspring.com [69.86.139.156]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 87A086A862F; Tue, 3 Oct 2006 22:32:32 -0700 (PDT) Message-ID: <45234767.5020004@mozilla.com> Date: Wed, 04 Oct 2006 01:32:23 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James M Snell CC: Atom Syntax Subject: Re: Atom and bidi References: <4522B295.3090704@gmail.com> <45231DE6.6040409@gmail.com> <45232DB3.1090706@mozilla.com> <452331DC.5030002@gmail.com> <45233C2D.8010602@mozilla.com> <452342A5.20609@gmail.com> In-Reply-To: <452342A5.20609@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: 08170828343bcf1325e4a0fb4584481c James M Snell wrote: > If that's the case, it would be great if you would provide a concrete > proposal that we can discuss or at least describe exactly what you're > looking for. > You seem to think I'm obligated to participate in a volumetocracy[1] in order to get my work done. I'm not, so there is no 'we'. -Rob [1] From owner-atom-syntax@mail.imc.org Wed Oct 04 03:19:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV12o-000712-N7 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 03:19:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV12l-0000bI-4O for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 03:19:54 -0400 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 k9471fTg043535; Wed, 4 Oct 2006 00:01: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 k9471fQu043534; Wed, 4 Oct 2006 00:01: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 mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9471dvc043436 for ; Wed, 4 Oct 2006 00:01:40 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20061004070106.KIRL27023.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Wed, 4 Oct 2006 08:01:06 +0100 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20061004070106.DAXH15733.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com> for ; Wed, 4 Oct 2006 08:01:06 +0100 Date: Wed, 4 Oct 2006 08:00:45 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <733368392.20061004080045@djpowell.net> To: atom-syntax Subject: Re: PaceAtomBidi In-Reply-To: <45232B7F.2060504@gmail.com> References: <45232B7F.2060504@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.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 It is hard to discuss the impacts without knowing what status we are trying to achieve with this and any other proposed changes to Atom. Are we planning on changing the Atom namespace? Adding inheritable attributes seems like a breaking to change. Existing compliant implementations will silently corrupt such feeds. Example (incomplete): rtl feed title this should be right to left If this feed is stored anywhere then, a) the undefined attribute may get lost; and b) even if it doesn't, stateful implementations won't know that they have to resolve each entry against it and store the attribute with the entry data as well as the feed data. Eg, if a later entry is posted to the same feed, and the feed polled as: rtl feed title this should be left right A stateful implementation needs to know that this implies a feed with the latest feed metadata: rtl feed title and two entries: this should be right to left this should be left right -- Dave From owner-atom-syntax@mail.imc.org Wed Oct 04 04:27:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV268-0005eW-S0 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 04:27:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV260-0000mp-EB for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 04:27:24 -0400 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 k9489bDX054600; Wed, 4 Oct 2006 01:09: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 k9489b9G054599; Wed, 4 Oct 2006 01:09: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.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9489ZBx054584 for ; Wed, 4 Oct 2006 01:09:36 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 Oct 2006 08:09:30 -0000 Received: from xdsl-213-196-221-120.netcologne.de (EHLO klangraum) [213.196.221.120] by mail.gmx.net (mp018) with SMTP; 04 Oct 2006 10:09:30 +0200 X-Authenticated: #163624 Date: Wed, 4 Oct 2006 10:09:29 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?] Message-ID: <20061004080929.GA7170@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4520B94C.6020209@mozilla.com> <4522EABA.4000009@dehora.net> <20061004005902.GM1618@klangraum> <4523110A.6020202@dehora.net> <452316EE.90500@mozilla.com> <4520B94C.6020209@mozilla.com> <4522EABA.4000009@dehora.net> <20061004005902.GM1618@klangraum> <4523110A.6020202@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <452316EE.90500@mozilla.com> <4523110A.6020202@dehora.net> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k9489bDX054600 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 * Bill de hOra [2006-10-04 03:55]: > A. Pagaltzis wrote: > >I think given the above background you'll agree that the > >intent of the document is pretty coherent.=20 >=20 > I couldn't tell whether new Atom extensions are foreign markup, > or something else to be dealt with under wrt being > a "forward-compatible" friendly consumer. It's kind of > circular. That=E2=80=99s what I meant. The intent is well thought-out and sharply defined (in the mathematical sense), but it=E2=80=99s specification in the document is not very explicit. It could stand to be clarified a bit so that people don=E2=80=99t have to ask on the list to have someone from the old boys club educate them before they know how to read the spec. Since you=E2=80=99re fresh from newly reading that section, how would it have had to read in order to convey its meaning clearly? * Robert Sayre [2006-10-04 04:20]: > Bill, please show us a bug? Bugs concerning forward compatibility are unlikely to surface prior to Atom getting revised in some form. It=E2=80=99d be good if the spec is clear enough that implementations have a chance to react interoperably in the eventuality of such revisions. It=E2=80=99s not some huge roadblocking issue, but neither is it without merit. If it can be removed with an extra sentence in the spec and a tweak to another and the opportunity is there, that seems like a worthwhile small win to me. Polish shows in the details. > I don't think defining terms until we've got a good subset of > an English dictionary will make the format more interoperable. Noone said anything about defining new terms. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Oct 04 06:52:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4Md-0004xc-Vd for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 06:52:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV4Mb-00055S-I4 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 06:52:35 -0400 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 k94APMJA078990; Wed, 4 Oct 2006 03:25: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 k94APMnh078989; Wed, 4 Oct 2006 03:25: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 mail.internode.on.net (bld-mail01.adl2.internode.on.net [203.16.214.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94APKVc078979 for ; Wed, 4 Oct 2006 03:25:21 -0700 (MST) (envelope-from arsptr@internode.on.net) Received: from [192.168.1.3] (unverified [59.167.25.208]) by mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 237731206 for multiple; Wed, 04 Oct 2006 19:55:13 +0930 (CST) In-Reply-To: <4522549C.7040207@metalab.unc.edu> References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> Cc: James M Snell , Bill de hOra , atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Alastair Rankine Subject: Re: Atom Export Date: Wed, 4 Oct 2006 20:25:10 +1000 To: Elliotte Harold X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On 03/10/2006, at 10:16 PM, Elliotte Harold wrote: > Perhaps it would be helpful to back up a step. Rather than starting > with format design let's try to get a list of everything we need to > include in this format. E.g. > > 1. Complete source text for every blog entry. > 2. Metadata for each blog entry > A. Title > B. Catgeory > C. Tags > 3. All media referenced by relative URLs from blog entry > 4. URL of blog entry > > What else? Well here's my list: 1. Complete list of authors and categories defined 2. For each article: a. Source text b. All the relevant metadata from the Atom spec, namely: author, ID, published, rights, title, updated, summary, categories c. Some other metadata: draft status, syntax of source d. "Owned" media, whether linked to in the source text or enclosure 3. For each comment or trackback: a. Source text b. Atom spec metadata: author, ID, title, published, summary, avatar? c. Additional metadata: pointer to parent article or comment (ie "in-reply-to") The tricky bit is defining what is meant by "owned" media. If we assume that an input to this process is a URL, I would say that "owned" media is any referenced media which resolves to the same host. This would preclude separately-hosted media (eg "images.example.com") but I don't see that this can be handled easily: how would an importer handle media destined for more than one host? I don't think it's worthwhile attempting to support arbitary differences between paths of the exported data and its desired import location. For example, I wouldn't expect to be able to migrate from http://example.com/blog to http://example.org/my/cool/blog AND have all the relative and absolute links to media magically work. So in a nutshell that's the problem I'm trying to solve. From owner-atom-syntax@mail.imc.org Wed Oct 04 06:59:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4TU-0000kP-9H for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 06:59:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV4TO-0006p9-Sv for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 06:59:40 -0400 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 k94ASuSS079739; Wed, 4 Oct 2006 03:28: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 k94ASufJ079738; Wed, 4 Oct 2006 03:28: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 bay0-omc3-s22.bay0.hotmail.com (bay0-omc3-s22.bay0.hotmail.com [65.54.246.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94AStef079710 for ; Wed, 4 Oct 2006 03:28:56 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.141]) by bay0-omc3-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 03:28:50 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Oct 2006 03:28:50 -0700 Message-ID: Received: from 81.179.103.143 by BAY120-DAV3.phx.gbl with DAV; Wed, 04 Oct 2006 10:28:46 +0000 X-Originating-IP: [81.179.103.143] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <45232B7F.2060504@gmail.com> Subject: Re: PaceAtomBidi Date: Wed, 4 Oct 2006 11:28:44 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 04 Oct 2006 10:28:50.0363 (UTC) FILETIME=[E1F8C0B0:01C6E79F] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > The attribute is optional and has three possible values, "ltr", > "rtl" and "" (representing 'unspecified'). If the attribute is missing, How about also allowing the values "lro" and "rlo" as used in xhtml2. [1] > Any element defined by this specification MAY have a "dir" attribute > whose content specifies the base direction of directionally-neutral text I was looking through the various Atom elements that this might apply to and the one thing that struck me as problematic was the atom:category element. Would the dir attribute apply to the term, the label, both, neither? Is that one of the cases where you should just use unicode control characters? Perhaps it would be better to limit the dir attribute to element content in general. Even for elements that only have one "text" attribute, you can never be sure that other attributes won't be added in the future. For example in atom:link you would think the direction would unambiguously apply to the title attribute, but say a future revision or extension added a description attribute - suddenly it's not so obvious anymore. Regards James [1] http://www.w3.org/TR/xhtml2/mod-bidi.html From owner-atom-syntax@mail.imc.org Wed Oct 04 08:16:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5fn-0004bd-DK for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 08:16:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV5fi-0002eJ-Ry for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 08:16:27 -0400 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 k94BpTHw096345; Wed, 4 Oct 2006 04:51: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 k94BpTMG096344; Wed, 4 Oct 2006 04:51: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94BpStu096337 for ; Wed, 4 Oct 2006 04:51:28 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 38030 invoked by uid 17064); 4 Oct 2006 11:51:27 -0000 Received: from unknown (HELO [192.168.1.5]) ([62.47.180.129]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Oct 2006 11:51:27 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) References: <452274A3.1040503@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7689D977-58F0-4382-9608-E6D482132B79@bblfish.net> Cc: Snell James , Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Fwd: Atom and bidi Date: Wed, 4 Oct 2006 13:51:41 +0200 To: atom-owl@googlegroups.com X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 The Atom Syntax group is discussing a bidi proposal (see end). I am not sure how much chance it has of getting through, and I don't understand the issues that well yet ( I have a few other things to do right now ), but I thought I should point out how I think it could impact AtomOwl. In a recent thread in this group entitled "Making Content into Literals in AtomOWL", I was arguing for using literals more in the AtomOwl ontology. Ie. I am suggesting that we convert Atom-Powered Robots Run Amok ... into [] a :Entry; :title "Atom-Powered Robots Run Amok"^^:text ; . Literals in rdf don't have space for a bidi encoding. There is space for language encoding such as "hello"@en^^:text but none for bidi. I suppose this is not really a problem as one could always encode this in unicode when needed or for xml fragments add it to a
in the content. If it really were a problem, then that may constitute an argument for using a content object. [] :title [ a :Content; :text "Atom-Powered Robots Run Amok"; :bidi :rtl; ] . Henry Begin forwarded message: > From: James M Snell > Date: 3 October 2006 16:33:07 GMT+02:00 > To: James Holderness > Cc: atom-syntax@imc.org > Subject: Re: Atom and bidi > > > Doh! I actually meant [RLE] here and not [RLO]. Either way, yes, I > know > there is a difference. The point I was trying to make is the same made > in HTML4-8.2: > > Although Unicode specifies special characters that deal with text > direction, HTML offers higher-level markup constructs that do the > same thing: the dir attribute (do not confuse with the DIR > element) > and the BDO element. Thus, to express a Hebrew quotation, it is > more > intuitive to write > > ...a Hebrew quotation... > > than the equivalent with Unicode references: > > ‫״...a Hebrew quotation...״‬ > > - James > > James Holderness wrote: >> >> James M Snell wrote: >>> just to be clear, I'm saying the following would be equivalent >>> (where >>> [RLO] and [PDF] represent the corresponding bidi controls) >>> >>> ABCDEFG >>> [RLO]ABCDEFG[PDF] >> >> You should be aware that there is a significant difference between >> RTL >> override, RTL embedding and the RTL direction attribute in HTML. >> >> Regards >> James >> >> From owner-atom-syntax@mail.imc.org Wed Oct 04 11:04:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8Ir-0005ly-PG for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 11:04:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8Iq-00015Y-Cc for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 11:04:57 -0400 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 k94ETTkJ033660; Wed, 4 Oct 2006 07:29: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 k94ETTZ3033658; Wed, 4 Oct 2006 07:29: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 ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94ETRa9033641 for ; Wed, 4 Oct 2006 07:29:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id 36so62661uga for ; Wed, 04 Oct 2006 07:29:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=I26kPfSxIqb+5cZoepDYX3GER8SntmxfAGNefoYaaZig1e9o76Yx31/EobsjlmCDYL4du10bOIiyutP+lEjY4IouvJvSzfls2LmmEaBG9CdWKLfM7atak9ESCaLo6fCgoQGYGnySHY4hat940JjSgv8TtTtbjv+FvgfRjVgeAPM= Received: by 10.78.200.20 with SMTP id x20mr554236huf; Wed, 04 Oct 2006 07:29:27 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 23sm809241hud.2006.10.04.07.29.25; Wed, 04 Oct 2006 07:29:26 -0700 (PDT) Message-ID: <4523C541.7010807@gmail.com> Date: Wed, 04 Oct 2006 07:29:21 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax Subject: Re: PaceAtomBidi References: <45232B7F.2060504@gmail.com> In-Reply-To: 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: 7baded97d9887f7a0c7e8a33c2e3ea1b James Holderness wrote: > >> The attribute is optional and has three possible values, "ltr", >> "rtl" and "" (representing 'unspecified'). If the attribute is missing, > > How about also allowing the values "lro" and "rlo" as used in xhtml2. [1] > Yeah, I'm just not yet sure whether these are strictly necessary. We need to explore this. >> Any element defined by this specification MAY have a "dir" attribute >> whose content specifies the base direction of directionally-neutral text > > I was looking through the various Atom elements that this might apply to > and the one thing that struck me as problematic was the atom:category > element. Would the dir attribute apply to the term, the label, both, > neither? Is that one of the cases where you should just use unicode > control characters? > The dir should only ever impact Language-Sensitive elements and attributes so term would not be affected but label would be. > Perhaps it would be better to limit the dir attribute to element content > in general. Even for elements that only have one "text" attribute, you > can never be sure that other attributes won't be added in the future. > For example in atom:link you would think the direction would > unambiguously apply to the title attribute, but say a future revision or > extension added a description attribute - suddenly it's not so obvious > anymore. > If the new attribute is Language-Sensitive then dir would apply. - James From owner-atom-syntax@mail.imc.org Wed Oct 04 11:40:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8rB-0000fP-90 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 11:40:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8r9-0000EV-RY for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 11:40:25 -0400 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 k94F8YS0039847; Wed, 4 Oct 2006 08:08: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 k94F8Yd0039846; Wed, 4 Oct 2006 08:08: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 wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94F8WX7039830 for ; Wed, 4 Oct 2006 08:08:33 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so39769wri for ; Wed, 04 Oct 2006 08:08:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=QQbG6cQoy1rtE/6v1GYef3HTqZ0Mtzx+9+a9T5i62RsWMR8jowwLqkk4x3AHJQdNqzMLJpfCgQy3y+xxeD/SjHt9j5ToHH3qALx4b9Zi3d7rUfk1/SP7Hg/EL+tgkBjnZdati6/iJEOuEI16GciE5q9GfXVpZqjFvAfyeUmCWCc= Received: by 10.90.52.18 with SMTP id z18mr241473agz; Wed, 04 Oct 2006 08:08:31 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 14sm1269264wrl.2006.10.04.08.08.30; Wed, 04 Oct 2006 08:08:31 -0700 (PDT) Message-ID: <4523CE66.4070204@gmail.com> Date: Wed, 04 Oct 2006 08:08:22 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Alastair Rankine CC: Elliotte Harold , Bill de hOra , atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> In-Reply-To: <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> 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: f4c2cf0bccc868e4cc88dace71fb3f44 Alastair Rankine wrote: > [snip] > Well here's my list: > > 1. Complete list of authors and categories defined With permissions, metadata, etc. > 2. For each article: > a. Source text > b. All the relevant metadata from the Atom spec, namely: > author, ID, published, rights, title, updated, summary, categories > c. Some other metadata: > draft status, syntax of source > d. "Owned" media, whether linked to in the source text or enclosure > 3. For each comment or trackback: > a. Source text > b. Atom spec metadata: > author, ID, title, published, summary, avatar? > c. Additional metadata: > pointer to parent article or comment (ie "in-reply-to") > I would add to this information about what plugins have been applied and what templates have been used. These, of course, are not going to be portable to different blog environments but the information would be necessary in order to faithfully recreate the entries later. > The tricky bit is defining what is meant by "owned" media. > > If we assume that an input to this process is a URL, I would say that > "owned" media is any referenced media which resolves to the same host. > This would preclude separately-hosted media (eg "images.example.com") > but I don't see that this can be handled easily: how would an importer > handle media destined for more than one host? > I would say that it's any media linked to by an entry located on the same host as the entry, with the exporter given some discretion as to what to include and what not to include. > I don't think it's worthwhile attempting to support arbitary differences > between paths of the exported data and its desired import location. For > example, I wouldn't expect to be able to migrate from > http://example.com/blog to http://example.org/my/cool/blog AND have all > the relative and absolute links to media magically work. > +1. It is the responsibility of the importer/exporter to make sure the references work. The export should result in an internally consistent package that can be processed without having to understand the URL structure of the original blog. - James From owner-atom-syntax@mail.imc.org Wed Oct 04 12:02:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9CF-0007oF-40 for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 12:02:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8yY-0001a5-Jk for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 11:48:03 -0400 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 k94FEcxE040763; Wed, 4 Oct 2006 08:14: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 k94FEcOi040761; Wed, 4 Oct 2006 08:14: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 bay0-omc3-s14.bay0.hotmail.com (bay0-omc3-s14.bay0.hotmail.com [65.54.246.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94FEZYo040736 for ; Wed, 4 Oct 2006 08:14:37 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.143]) by bay0-omc3-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 08:14:30 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Oct 2006 08:14:30 -0700 Message-ID: Received: from 81.179.103.143 by BAY120-DAV5.phx.gbl with DAV; Wed, 04 Oct 2006 15:14:26 +0000 X-Originating-IP: [81.179.103.143] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <45232B7F.2060504@gmail.com> <4523C541.7010807@gmail.com> Subject: Re: PaceAtomBidi Date: Wed, 4 Oct 2006 16:14:24 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 04 Oct 2006 15:14:30.0285 (UTC) FILETIME=[CA294BD0:01C6E7C7] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 James M Snell wrote: > James Holderness wrote: >> How about also allowing the values "lro" and "rlo" as used in xhtml2. [1] > > Yeah, I'm just not yet sure whether these are strictly necessary. We > need to explore this. I don't think they are necessary - you can probably get by with Unicode control chars - but it might be a good idea for consistency. Otherwise you'll sometimes be using the dir attribute and sometimes Unicode control chars. > The dir should only ever impact Language-Sensitive elements and > attributes so term would not be affected but label would be. Ok. I missed that. >> For example in atom:link you would think the direction would >> unambiguously apply to the title attribute, but say a future revision or >> extension added a description attribute - suddenly it's not so obvious >> anymore. > > If the new attribute is Language-Sensitive then dir would apply. But that means you can't have one attribute being RTL and the other LTR (say an Arabic title with an English description). Regards James From owner-atom-syntax@mail.imc.org Wed Oct 04 14:34:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBZT-0007NO-Uo for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 14:34:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBZP-0005Jf-EA for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 14:34:19 -0400 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 k94IDAo1066204; Wed, 4 Oct 2006 11:13: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 k94IDAhn066203; Wed, 4 Oct 2006 11:13: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-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 k94ID7tf066180 for ; Wed, 4 Oct 2006 11:13:09 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (unknown [207.126.230.225]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 28E4EA32A0 for ; Wed, 4 Oct 2006 14:13:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Wed, 4 Oct 2006 11:13:06 -0700 To: Atom-Syntax Syntax X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 I've only had positive comments about -07 so far, so I've recommended it for publication as a Proposed Standard to the IESG. As part of that process, I'm issuing an informal, pseudo-WG Last Call on the document to capture any remaining feedback. In particular, * What do people think about putting this document on the Standards Track? * Do you have an implementation available, in progress, planned, etc.? http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/ Please provide feedback by October 18th. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Oct 04 15:15:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCCw-0005yl-0O for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 15:15:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCCu-0003bv-Er for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 15:15:05 -0400 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 k94IkEs0070395; Wed, 4 Oct 2006 11:46: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 k94IkERr070394; Wed, 4 Oct 2006 11:46: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94IkDuP070388 for ; Wed, 4 Oct 2006 11:46:13 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so260127wxc for ; Wed, 04 Oct 2006 11:46:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ln6IebKhuUchXH3/dX+MsliWqNG8RPqWyEZJz/mVlVZ0vPBfuh7aCK8HP30vzxPA5sPNgdlhUdcZvPeRdPlL8zXHXD8XuhLUh32CMsmc+7FmhVkPMCsU8xUKoQWU80powUBmXjdfrbBZEzJP0iccbm1HDff5thNlIQLvZtxrSSE= Received: by 10.90.118.10 with SMTP id q10mr485783agc; Wed, 04 Oct 2006 11:46:11 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 28sm1703047wrl.2006.10.04.11.46.11; Wed, 04 Oct 2006 11:46:11 -0700 (PDT) Message-ID: <4524016E.6090604@gmail.com> Date: Wed, 04 Oct 2006 11:46:06 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax Subject: Re: PaceAtomBidi References: <45232B7F.2060504@gmail.com> <4523C541.7010807@gmail.com> In-Reply-To: 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: b19722fc8d3865b147c75ae2495625f2 James Holderness wrote: > [snip] >> >> Yeah, I'm just not yet sure whether these are strictly necessary. We >> need to explore this. > > I don't think they are necessary - you can probably get by with Unicode > control chars - but it might be a good idea for consistency. Otherwise > you'll sometimes be using the dir attribute and sometimes Unicode > control chars. > I had imagined that the feed consumer would decide whether to treat the dir as an embed or an explicit override depending on context. If the feed publisher wants to set the direction without any ambiguity, then they should use the unicode controls or the (x)html mechansisms (where appropriate). >>[snip] >> If the new attribute is Language-Sensitive then dir would apply. > > But that means you can't have one attribute being RTL and the other LTR > (say an Arabic title with an English description). > Right. Folks who really want to do this can achieve it using the unicode controls. - James From owner-atom-syntax@mail.imc.org Wed Oct 04 16:01:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCvq-0003Ag-4w for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 16:01:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCvo-0002oT-ID for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 16:01:30 -0400 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 k94Jk2Vf079359; Wed, 4 Oct 2006 12:46: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 k94Jk2rV079358; Wed, 4 Oct 2006 12:46: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 wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94Jk13s079347 for ; Wed, 4 Oct 2006 12:46:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so105655wri for ; Wed, 04 Oct 2006 12:46:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EmRfNTe6Hu8t4fbh70aI7b1nBptN5Rx/X5p0d6zgWTkrpbOSnSmzHqg5FgKdiO+kAdTsLTAPMsr1XnKZDuADfBUcVqvpJPkOmkbeeTmpfG6Ac8++cj9ED5s7fFEA+A6xr905QOKxHDrHLw31OZCHuBHNce/mmMldRYz3uH+CI0s= Received: by 10.90.52.2 with SMTP id z2mr543261agz; Wed, 04 Oct 2006 12:46:00 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 44sm1049606wri.2006.10.04.12.45.59; Wed, 04 Oct 2006 12:46:00 -0700 (PDT) Message-ID: <45240F72.4000304@gmail.com> Date: Wed, 04 Oct 2006 12:45:54 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Mark Nottingham CC: Atom-Syntax Syntax Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: In-Reply-To: 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: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Are you aware of Atom feeds that are currently implementing this version of the draft? I'd like to do some interop testing. - James Mark Nottingham wrote: > > I've only had positive comments about -07 so far, so I've recommended it > for publication as a Proposed Standard to the IESG. > > As part of that process, I'm issuing an informal, pseudo-WG Last Call on > the document to capture any remaining feedback. In particular, > > * What do people think about putting this document on the Standards Track? > > * Do you have an implementation available, in progress, planned, etc.? > > http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/ > > Please provide feedback by October 18th. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Wed Oct 04 22:44:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJDe-00052I-0C for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 22:44:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVJDb-0008Hx-JW for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 22:44:17 -0400 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 k9522XIG018222; Wed, 4 Oct 2006 19:02: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 k9522XfE018219; Wed, 4 Oct 2006 19:02: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9522Vx0018206 for ; Wed, 4 Oct 2006 19:02:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so381687wxc for ; Wed, 04 Oct 2006 19:02:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=I1AiVN06Eou62JsFXWG4Q5e8JfzFLrQJW9cYOgCodAyUMGPN27WJOZMl+XTOw7J3NBcZ4dJ3o4XzaJtoIAFv1y5PxeOt9TBVQ9gKMnpC50Y5kV3j4V6K/SVa9ibOZXFQX9oT/gq6dKBxqTgAayQV/B4Nb+8nO4Z67wMlaZ6B2tc= Received: by 10.70.109.9 with SMTP id h9mr2232169wxc; Wed, 04 Oct 2006 19:02:31 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.google.com with ESMTP id 11sm417625wrl.2006.10.04.19.02.30; Wed, 04 Oct 2006 19:02:31 -0700 (PDT) Message-ID: <452467B2.2000502@gmail.com> Date: Wed, 04 Oct 2006 19:02:26 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: rss-public@yahoogroups.com, atom-syntax Subject: Re: [rss-public] Re: Bidirectional content in RSS References: <452296B0.6010701@gmail.com> <452443D7.1080408@gmail.com> In-Reply-To: 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: 8b30eb7682a596edff707698f4a80f7d (cross posted to the atom-syntax list) James Holderness wrote: > [snip] > So if you want to go with the bare minimum, then you should really be > limiting yourself to a dir attribute on descriptions elements and nothing > else. If you aren't going with the bare minimum then I'd argue for a > consistent application of all form of direction encoding. I think it's > clearer and less confusing. > Ok, I can understand the argument and although I can't imagine any real world use cases, I can see how the lro and rlo values could be used. The only harm in allowing them is a bit more complexity and an additional requirement on the part of readers displaying the text (e.g. that they treat it as an explicit override. I can go ahead and add these to the proposed definition of the atom dir attribute. However, I'm wondering how this could work in RSS given that we, apparently, cannot have extension attributes in RSS. (I would, btw, be very interested in hearing Dave's opinion on whether or not extension attributes in RSS are allowed). Perhaps a "bidi:dir" extension element on the channel and item elements could be used? e.g. ... he rtl ... It's imperfect, of course, but that's pretty much par for the course. - James From owner-atom-syntax@mail.imc.org Wed Oct 04 23:40:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVK61-0006jF-MI for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 23:40:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVK5x-0005xr-2p for atompub-archive@lists.ietf.org; Wed, 04 Oct 2006 23:40:29 -0400 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 k9537I79025453; Wed, 4 Oct 2006 20:07: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 k9537IHP025452; Wed, 4 Oct 2006 20:07: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9537Glc025445 for ; Wed, 4 Oct 2006 20:07:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so682876nfa for ; Wed, 04 Oct 2006 20:07:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Sq8l3OJzqPDhSZeGc4mKNtewkAdFXF0MEGVWFA8+uJGvAquBonFNznVIdU5XtJM9xN9v+wdqhatNe2IHNr5C5uVFIMDX/IxtoySrkyKO/6h8HZH5UzBfAbunKffDEE15wbni+qmbjZA3LJUMnmkqcp7MJNZ1lVRV4a25YG/6sLg= Received: by 10.78.178.5 with SMTP id a5mr864725huf; Wed, 04 Oct 2006 20:07:15 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.google.com with ESMTP id 8sm266508hug.2006.10.04.20.07.13; Wed, 04 Oct 2006 20:07:14 -0700 (PDT) Message-ID: <452476DC.3090708@gmail.com> Date: Wed, 04 Oct 2006 20:07:08 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceAtomBidi References: <45232B7F.2060504@gmail.com> In-Reply-To: <45232B7F.2060504@gmail.com> 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: cd3fc8e909678b38737fc606dec187f0 I've updated the Pace (apppended below) to include the "rlo" and "lro" dir attr values as suggested by James Holderness. I'm definitely not happy with the wording, tho. Example: Testing Would be generally equivalent to: <div xmlns="..."> <bdo dir="rtl">Testing</bdo> </div> and [RLO]Testing[PDF] (where [RLO] == the Unicode Right-to-Left Override and [PDF] == the Unicode Pop-directional format ) Even with this attribute, achieving proper mixed directionality in plain text still requires the use of unicode control chars, e.g. Testing "[RLM]A Hebrew Quotation![RLM]" Testing (where [RLM] == the Unicode Right-to-Left Mark) As an alternative, this whole thing can be defined in an extension rather than as a part of the core spec. Thoughts? - James --------------------------- http://www.intertwingly.net/wiki/pie/PaceAtomBidi #pragma section-numbers off == Abstract == RFC4287 currently has no *efficient* means of indicating the base directionality of text. While the Unicode bidi control characters can be used, they can be problematic to use correctly within XML and do not allow publishers to set a single default direction for a complete Atom document. This proposal adds a new common attribute to all Atom elements called "dir". The attribute is optional and has three possible values, "ltr", "rtl" and "" (representing 'unspecified'). If the attribute is missing, the value is considered to be unspecified. This should make the element fully backwards compatible with existing compliant RFC4287 implementations that properly handle "unknown markup". This proposal does add the requirement that bidi text in atom docs MUST be rendered using the unicode bidi algorithm but makes it clear that the use of dir on an element does not necessarily open a new level of embedding... meaning that feed consumers have the responsibility of determining how to apply the bidi algorithm based on how those consumers choose to display the text (e.g. some readers may display entry content in a
while others may display content in a , both of which handle bidi text differently depending on context). I also specify that bidi text in (x)html should use the bidi markup as defined by those specs. == Status == Proposed. == Rationale == (see abstract) == Proposal == {{{ 2.0 Add "dir" to atomCommonAttributes atomCommonAttributes = attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }?, attribute dir { "ltr" | "rtl" | "lro" | "rlo" | "" }?, undefinedAttribute* 2.1 The "dir" Attribute Any element defined by this specification MAY have a "dir" attribute whose content specifies the base direction of directionally-neutral text [UNICODE]. Possible values for the attribute are "ltr" and "rtl" indicating "left-to-right" and "right-to-left" respectively, "lro" and "rlo" indicating explicit "left-to-right" and "right-to-left" overrides, or an empty string "" indicating that no base-direction is unspecified. If the "dir" attribute is not specified, the value is assumed to be an empty string. The direction specified by "dir" applies only to elements and attributes whose values are specified as being "Language-Sensitive". The attribute is inherited by descendent elements and may be overridden. Example atom:feed with right-to-left directionality ٹٺٻ ... If an Atom document contains any right-to-left characters, the Unicode Bidirectional Algorithm [UAX#9] MUST be used to render that text. Because consumers of Atom documents vary broadly in the way they display text, the "ltr" and "rtl" values do not necessarily open an additional level of embedding with respect to the bidirectional algorithm. Consuming applications that render bidirectional text are responsible for determining the appropriate level of embedding. The "lro" and "rlo" values are used to override the inherent directionality of characters as defined by [UNICODE]. When Atom Text Constructs or the atom:content elements contain bidirectional text and the type attribute is set to either "html" or "xhtml", the bidirectional markup mechanisms specific to each format SHOULD be used. Example atom:feed with bidirectional XHTML <div xmlns="http://www.w3.org/1999/xhtml"> <p dir="rtl">ٹٺٻ</p> </div> ... The Unicode bidirectional control characters MAY also be used within attributes and element values to indicate the directionality of text. IRI's containing bidirectional characters MUST be stored, transmitted and rendered as defined in [RFC3987] Section 4. }}} == Impacts == == Notes == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Thu Oct 05 01:28:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVLmP-0001D8-82 for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 01:28:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVLgn-0002Z9-QP for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 01:22:36 -0400 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 k954loQO036972; Wed, 4 Oct 2006 21:47: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 k954lom2036971; Wed, 4 Oct 2006 21:47: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-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 k954lnAS036964 for ; Wed, 4 Oct 2006 21:47:50 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.3] (unknown [71.131.39.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9B765A3202; Thu, 5 Oct 2006 00:47:47 -0400 (EDT) In-Reply-To: <45240F72.4000304@gmail.com> References: <45240F72.4000304@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36A1C2D3-A1C3-4AF8-87C4-3480DDEDE440@mnot.net> Cc: Atom-Syntax Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Wed, 4 Oct 2006 21:47:49 -0700 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 My blog has conformant RSS and Atom archived feeds. I also have a demonstration implementation of a client that will reconstruct archived feeds; Others? I know paging is used informally a lot in other situations/ specs. On 2006/10/04, at 12:45 PM, James M Snell wrote: > Are you aware of Atom feeds that are currently implementing this > version > of the draft? I'd like to do some interop testing. > > - James > > Mark Nottingham wrote: >> >> I've only had positive comments about -07 so far, so I've >> recommended it >> for publication as a Proposed Standard to the IESG. >> >> As part of that process, I'm issuing an informal, pseudo-WG Last >> Call on >> the document to capture any remaining feedback. In particular, >> >> * What do people think about putting this document on the >> Standards Track? >> >> * Do you have an implementation available, in progress, planned, >> etc.? >> >> http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed- >> history/ >> >> Please provide feedback by October 18th. >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Oct 05 10:43:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVURA-0002GH-DX for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 10:43:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUR6-0001Ua-0y for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 10:43:00 -0400 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 k95EGmnZ010495; Thu, 5 Oct 2006 07:16: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 k95EGmfg010492; Thu, 5 Oct 2006 07:16: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k95EGiKe010475 for ; Thu, 5 Oct 2006 07:16:47 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 05 Oct 2006 14:16:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp044) with SMTP; 05 Oct 2006 16:16:39 +0200 X-Authenticated: #1915285 Message-ID: <452513C6.6070907@gmx.de> Date: Thu, 05 Oct 2006 16:16:38 +0200 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: Mark Nottingham CC: atom-syntax@imc.org Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Mark Nottingham schrieb: > > I've only had positive comments about -07 so far, so I've recommended it > for publication as a Proposed Standard to the IESG. > > As part of that process, I'm issuing an informal, pseudo-WG Last Call on > the document to capture any remaining feedback. In particular, > > * What do people think about putting this document on the Standards Track? > > * Do you have an implementation available, in progress, planned, etc.? > > http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/ > > Please provide feedback by October 18th. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ Looks all good to me, except for the nits below: - you want to update the xml-names reference to - you may want to change the xml2rfc list style in Section 5 to "empty" Best regards, Julian From owner-atom-syntax@mail.imc.org Thu Oct 05 11:14:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUvv-0007DS-Ep for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 11:14:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUvu-0007X0-1G for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 11:14:47 -0400 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 k95Eo9nA013903; Thu, 5 Oct 2006 07:50: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 k95Eo9M1013902; Thu, 5 Oct 2006 07:50: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 ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95Eo7FO013863 for ; Thu, 5 Oct 2006 07:50:09 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id C9DB526E46; Thu, 5 Oct 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVUXx-0004Jh-MW; Thu, 05 Oct 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-protocol-11.txt Message-Id: Date: Thu, 05 Oct 2006 10:50:01 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Publishing Protocol Author(s) : B. de Hora, J. Gregorio Filename : draft-ietf-atompub-protocol-11.txt Pages : 52 Date : 2006-10-5 The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format [RFC4287]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-protocol-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-protocol-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-5095512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-protocol-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-protocol-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-5095512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Thu Oct 05 16:21:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZiJ-0008Gs-KA for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 16:21:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZiG-0007R5-4b for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 16:21:03 -0400 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 k95JtoYE049286; Thu, 5 Oct 2006 12:55: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 k95JtoEY049285; Thu, 5 Oct 2006 12:55: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 mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95JtlP3049272 for ; Thu, 5 Oct 2006 12:55:49 -0700 (MST) (envelope-from davidh@yahoo-inc.com) Received: from SNV-XCHMAIL2.xch.corp.yahoo.com (snv-xch3.xch.corp.yahoo.com [207.126.227.242]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k95JtObf080970 for ; Thu, 5 Oct 2006 12:55:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:from:to; b=vfx/ijVlsxssslRfQsfGyno5h1mKyS4yOC4ovpsegHzMkrQc8Umw/un7mecWtGgw X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Thu, 5 Oct 2006 12:55:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Thread-Index: AcbotFL/xGaJlcpfRaqF6iJ6fHJSRwAAJEEA From: "David Hall" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k95JtnP3049279 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hey Mark - Things are looking good to me. Couple questions, comments: 1. I think your document might need to address what's supposed to happen if duplicate items are discovered when trolling through the paged info. Newer replaces older? (That makes the most sense to me) Although I guess the argument might be, "what's an 'item'?". 2. We're currently recommending 'feed history' as a best practice for Media RSS. http://search.yahoo.com/mrss (I'll need to update that link in the documentation) Thanks- David > From: Mark Nottingham > Date: 4 October 2006 11:13:06 AM > To: Atom-Syntax Syntax > Subject: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 > > > I've only had positive comments about -07 so far, so I've > recommended it for publication as a Proposed Standard to the IESG. > > As part of that process, I'm issuing an informal, pseudo-WG Last > Call on the document to capture any remaining feedback. In particular, > > * What do people think about putting this document on the Standards > Track? > > * Do you have an implementation available, in progress, planned, etc.? > > http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed- > history/ > > Please provide feedback by October 18th. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Oct 05 17:44:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb1G-0008Bv-QY for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 17:44:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVasn-0001AK-Fq for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 17:36:01 -0400 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 k95L9dqf056831; Thu, 5 Oct 2006 14:09: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 k95L9dB7056830; Thu, 5 Oct 2006 14:09: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 mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95L9bhh056818 for ; Thu, 5 Oct 2006 14:09:38 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.241.143] (sera-10-169-186-35.nscp.aoltw.net [10.169.186.35]) by mcom.com (8.10.0/8.10.0) with ESMTP id k95L9KW01574 for ; Thu, 5 Oct 2006 14:09:25 -0700 (PDT) Message-ID: <45257480.3070705@aol.net> Date: Thu, 05 Oct 2006 14:09:20 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Searching for Atom-enabled code 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.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Using Google codesearch: Java: http://google.com/codesearch?hl=en&lr=&q=lang%3Ajava+application%2Fatom%5C%2Bxml&btnG=Search (50 results) C++: http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%2B%2B+application%2Fatom%5C%2Bxml&btnG=Search (10 results) Ruby: http://google.com/codesearch?hl=en&lr=&q=lang%3Aruby+application%2Fatom%5C%2Bxml&btnG=Search (50 results) Perl: http://google.com/codesearch?hl=en&lr=&q=lang%3Aperl+application%2Fatom%5C%2Bxml&btnG=Search (100 results) C#: http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%23+application%2Fatom%5C%2Bxml&btnG=Search (9 results) -- John Panzer System Architect, AOL http://abstractioneer.org From owner-atom-syntax@mail.imc.org Thu Oct 05 19:28:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVcdo-0003XU-HV for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 19:28:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVcdh-00071o-Tz for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 19:28:36 -0400 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 k95NAqfU065600; Thu, 5 Oct 2006 16:10: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 k95NAq4F065598; Thu, 5 Oct 2006 16:10: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 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 k95NAhql065579 for ; Thu, 5 Oct 2006 16:10:50 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061005231035.MDLI1865.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Fri, 6 Oct 2006 00:10:35 +0100 Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20061005231035.LJJI15733.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com> for ; Fri, 6 Oct 2006 00:10:35 +0100 Date: Fri, 6 Oct 2006 00:10:21 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <476750322.20061006001021@djpowell.net> To: atom-syntax Subject: Re: PaceAtomBidi In-Reply-To: <452476DC.3090708@gmail.com> References: <45232B7F.2060504@gmail.com> <452476DC.3090708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k95NApql065593 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 k95NAqfU065600 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 I don't have much experience with bidi. I've been having a quick read up on it, and there seem to be the following features. Correct me if I=E2=80=99m wrong. a) Unicode implicitly supports bidi. Write a span containing Hebrew characters, and it will be laid out right to left. We don=E2=80=99t need = to do anything to support this. b) and Unicode controls such as RIGHT-TO-LEFT EMBEDDING, give hints about how to layout neutral characters such as punctuation marks that are used between flows of ltr and rtl text. We don=E2=80=99t need to do anything to support these Unicode controls. can be used in Text constructs if required, but such a mechanism isn=E2=80=99t necessary for the rest of Atom. HTML benefits from because it is easier to type it in HTML source than Unicode escapes, but nobody really types Atom source by hand, and operating systems do support embedding of Unicode escapes via text widgets (eg, on Windows, install supplemental language support via Regional Settings control panel - I think?). Allowing dir to be used anywhere in Atom does not provide the same feature as , because the sole purpose of it is to disambiguate mixed directions *within* a flow of text, and allowing @dir anywhere in Atom would not achieve that granularity. c) and Unicode controls such as RIGHT-TO-LEFT OVERRIDE allow the Unicode algorithm to be disabled and direction to be hard-coded. Under what circumstances is this needed? Is it appropriate for Atom? d)
sets the base direction of the text. One of the effects of this is that
makes paragraphs right aligned, and table columns to be laid out right-to-left. I'm not convinced that we need support for this in Atom. I'd like to hear more opinions. In HTML it makes sense to specify that a block of text is right-aligned, but in Atom there are no blocks of text; just fields. Isn't this largely a presentation feature? Adding an attribute that is supposed to inherit from feed elements to entry elements is a breaking change to Atom that is likely to lead to silent data-loss with existing implementations. Implementations would need to know to inherit the attribute down to entries and store it with the entries rather than with the feed, so that retrospective changes don't change the direction of previously polled entries. I think that inheritance is useful for a hierarchically structured document like HTML, but confusing for Atom, which is essentially a bunch of XML-ified structs with a fairly arbitrary hierarchy representing multiple entities with seperate life-cycles. (People deal with feeds containing a subset of all entries ever, not with feed documents) e) in IE at least, this affects not only the page, but the layout of browser chrome such as scrollbars and Javascript alerts. I don't think that this feature is appropriate for syndication format. The user preferences of the user-agent (probably via the OS) would probably be better suited to control the application layout. So, the question is: do we need the ability to markup the "base direction" of text in Atom, at a block level. If so, what are the applications of the "base direction" in Atom's layout-agnostic fields such as category label? Also at what granularity do we need to do this? On every element, or would it be sufficient to use extension elements to describe the base direction at the entry/feed level (cf: ) ? --=20 Dave From owner-atom-syntax@mail.imc.org Thu Oct 05 20:24:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVdVh-0007zE-5N for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 20:24:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVdKt-000442-GX for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 20:13:09 -0400 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 k95NwmFe070401; Thu, 5 Oct 2006 16:58: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 k95Nwmtd070400; Thu, 5 Oct 2006 16:58: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95NwkNk070394 for ; Thu, 5 Oct 2006 16:58:48 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so973273nfa for ; Thu, 05 Oct 2006 16:58:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qcaslkzReGGkt3phovbphymBp91tM3xn4b6Dih1zVyscDA6CmhrgTCgdd3vJINXlkQkxATXdNS4WppvuVP9seXcdWgksV76otQ3tgIvWRoV5WW8XOukn4IxEaSUEaHMVUa7Q12PUjz3qI4fR92UpLfaGUUc/mEPTRQTugQrc3GY= Received: by 10.78.182.20 with SMTP id e20mr997084huf; Thu, 05 Oct 2006 16:58:45 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.google.com with ESMTP id 20sm1575971huf.2006.10.05.16.58.42; Thu, 05 Oct 2006 16:58:44 -0700 (PDT) Message-ID: <45259C2B.6070804@gmail.com> Date: Thu, 05 Oct 2006 16:58:35 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceAtomBidi References: <45232B7F.2060504@gmail.com> <452476DC.3090708@gmail.com> <476750322.20061006001021@djpowell.net> In-Reply-To: <476750322.20061006001021@djpowell.net> Content-Type: text/plain; charset=UTF-8 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 k95NwmFe070401 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd David Powell wrote: >=20 >=20 > I don't have much experience with bidi. I've been having a quick read > up on it, and there seem to be the following features. Correct me if > I=E2=80=99m wrong. >=20 >=20 > a) Unicode implicitly supports bidi. Write a span containing Hebrew > characters, and it will be laid out right to left. We don=E2=80=99t nee= d to do > anything to support this. >=20 Only if rendered using the Unicode Bidirectional Algorithm. >=20 > b) and Unicode controls such as RIGHT-TO-LEFT > EMBEDDING, give hints about how to layout neutral characters such as > punctuation marks that are used between flows of ltr and rtl text. We > don=E2=80=99t need to do anything to support these Unicode controls. dir> can be used in Text constructs if required, but such a mechanism > isn=E2=80=99t necessary for the rest of Atom. >=20 Not quite. Suppose, for instance, I have a category whose label attribute consists of primarily (but not completely) right-to-left text. Example taken from http://www.w3.org/International/articles/inline-bidi-markup/#visual). Uppercase letters represent RTL characters. When displayed, using the bidi algorithm, this should be rendered as "W3C, GFEDCBA". However, absent any directional information, it will be incorrectly rendered as "GFEDCBA, W3C". To get the direction correct in (x)html, we either need to wrap the value using the unicode controls or use something like . In Atom, the only current option is to wrap use the numeric entity codes, e.g., If you have multiple categories, text elements, etc that all contain primarily RTL text, having to wrap all of the text values like this gets to be quite annoying and problematic. > HTML benefits from because it is easier to type it in HTML > source than Unicode escapes, but nobody really types Atom source by > hand, and operating systems do support embedding of Unicode escapes > via text widgets (eg, on Windows, install supplemental language > support via Regional Settings control panel - I think?). Allowing dir > to be used anywhere in Atom does not provide the same feature as dir>, because the sole purpose of it is to disambiguate mixed > directions *within* a flow of text, and allowing @dir anywhere in Atom > would not achieve that granularity. >=20 This is precisely why the Pace gives discretion to the consuming application on how to apply the bidi alg. The dir attribute in Atom would serve only to specify the base directionality of neutral characters contained in the feed (equivalent to explicitly wrapping affected text in the equivalent unicode bidi embed codes). >=20 > c) and Unicode controls such as RIGHT-TO-LEFT OVERRID= E > allow the Unicode algorithm to be disabled and direction to be > hard-coded. Under what circumstances is this needed? Is it > appropriate for Atom? >=20 I imagine the "lro" and "rlo" values being used very rarely, if ever. >=20 > d)
sets the base direction of the text. One of the > effects of this is that
makes paragraphs right > aligned, and table columns to be laid out right-to-left. >=20 > I'm not convinced that we need support for this in Atom. I'd like to > hear more opinions. In HTML it makes sense to specify that a block of > text is right-aligned, but in Atom there are no blocks of text; just > fields. Isn't this largely a presentation feature? >=20 Again, the Pace defers the responsibility of how to apply the bidi alg to consuming applications. For instance, some feed readers may choose to display a RTL title in a block element while others may choose to display it in an in-line element; both of which will yield different results. > Adding an attribute that is supposed to inherit from feed elements to > entry elements is a breaking change to Atom that is likely to lead to > silent data-loss with existing implementations. Implementations would > need to know to inherit the attribute down to entries and store it > with the entries rather than with the feed, so that retrospective > changes don't change the direction of previously polled entries. >=20 Yes, but this doesn't leave us any worse off than we currently are. Implementations that are not direction-aware should treat the new attribute as foreign markup and drop the data on the floor. Those implementations should continue to work as the do currently. Further, implementors already need to deal with such issues with regards to author, rights, xml:base and xml:lang so we're not introducing a new problem. > I think that inheritance is useful for a hierarchically structured > document like HTML, but confusing for Atom, which is essentially a > bunch of XML-ified structs with a fairly arbitrary hierarchy > representing multiple entities with seperate life-cycles. (People deal > with feeds containing a subset of all entries ever, not with feed > documents) >=20 >=20 > e) in IE at least, this affects not only the page, > but the layout of browser chrome such as scrollbars and Javascript > alerts. I don't think that this feature is appropriate for syndication > format. The user preferences of the user-agent (probably via the OS) > would probably be better suited to control the application layout. >=20 Atom does not dictate the behavior of user agents. Adding a dir attribute would not change that fact. >=20 > So, the question is: do we need the ability to markup the "base > direction" of text in Atom, at a block level. If so, what are the > applications of the "base direction" in Atom's layout-agnostic fields > such as category label? >=20 Strictly speaking, we can achieve the same result by using the unicode bidi controls but doing so can be tricky at times. The dir attribute makes life easier. > Also at what granularity do we need to do this? On every element, or > would it be sufficient to use extension elements to describe the base > direction at the entry/feed level (cf: ) ? >=20 The attribute should be capable of appearing anywhere xml:lang can appear and like xml:lang, only affects certain elements and attributes in the feed. However, whether or not this works best as an attribute in the Atom namespace or an attribute in some other extension namespace is an open question. - James From owner-atom-syntax@mail.imc.org Thu Oct 05 20:32:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVddx-0004dd-Ur for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 20:32:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVddt-0003S5-If for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 20:32:49 -0400 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 k960JxpU072111; Thu, 5 Oct 2006 17:19: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 k960JxTJ072110; Thu, 5 Oct 2006 17:19: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k960JwCv072104 for ; Thu, 5 Oct 2006 17:19:58 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so729728wxc for ; Thu, 05 Oct 2006 17:19:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LsJ/jSX542Jud1ohiWLqguCdHuInVoJQuHIFeh+JRdB4mqN1Nc1CoZiM1U6or2zwGggF44XEkCUV2E2PWGKeasL6i4FTh8SqujDmfF6h5+IVlYOvdmDlVWVqEeeAPG3ROMR2xgsGkir9KC5vXpWadMFJ6r4vHy+ErRvPBdG1WkQ= Received: by 10.70.22.10 with SMTP id 10mr4168558wxv; Thu, 05 Oct 2006 17:19:58 -0700 (PDT) Received: by 10.70.71.2 with HTTP; Thu, 5 Oct 2006 17:19:57 -0700 (PDT) Message-ID: <3f1451f50610051719v46d0d6afjac2d319c59ef3ec3@mail.gmail.com> Date: Thu, 5 Oct 2006 20:19:57 -0400 From: "Joe Gregorio" To: "John Panzer" Subject: Re: Searching for Atom-enabled code Cc: "Atom Syntax" In-Reply-To: <45257480.3070705@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45257480.3070705@aol.net> X-Google-Sender-Auth: 83f247516e6d20eb Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b How dare you slight my favorite language :) http://google.com/codesearch?hl=en&lr=&q=lang%3Apython+application%2Fatom%5C%2Bxml&btnG=Search (100 results) Python -joe On 10/5/06, John Panzer wrote: > > Using Google codesearch: > > Java: > http://google.com/codesearch?hl=en&lr=&q=lang%3Ajava+application%2Fatom%5C%2Bxml&btnG=Search > (50 results) > C++: > http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%2B%2B+application%2Fatom%5C%2Bxml&btnG=Search > (10 results) > Ruby: > http://google.com/codesearch?hl=en&lr=&q=lang%3Aruby+application%2Fatom%5C%2Bxml&btnG=Search > (50 results) > Perl: > http://google.com/codesearch?hl=en&lr=&q=lang%3Aperl+application%2Fatom%5C%2Bxml&btnG=Search > (100 results) > C#: > http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%23+application%2Fatom%5C%2Bxml&btnG=Search > (9 results) > > -- > John Panzer > System Architect, AOL > http://abstractioneer.org > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Oct 05 23:56:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVgoa-0002qj-1f for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 23:56:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVgcr-0008J2-4R for atompub-archive@lists.ietf.org; Thu, 05 Oct 2006 23:43:58 -0400 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 k963QCHq084315; Thu, 5 Oct 2006 20:26: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 k963QCuO084314; Thu, 5 Oct 2006 20:26: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.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k963QAmX084304 for ; Thu, 5 Oct 2006 20:26:11 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 06 Oct 2006 03:26:04 -0000 Received: from xdsl-81-173-169-190.netcologne.de (EHLO klangraum) [81.173.169.190] by mail.gmx.net (mp010) with SMTP; 06 Oct 2006 05:26:04 +0200 X-Authenticated: #163624 Date: Fri, 6 Oct 2006 05:26:03 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Searching for Atom-enabled code Message-ID: <20061006032603.GL11143@klangraum> Mail-Followup-To: Atom Syntax References: <45257480.3070705@aol.net> <3f1451f50610051719v46d0d6afjac2d319c59ef3ec3@mail.gmail.com> <45257480.3070705@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3f1451f50610051719v46d0d6afjac2d319c59ef3ec3@mail.gmail.com> <45257480.3070705@aol.net> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k963QCHq084315 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi John, * John Panzer [2006-10-05 23:25]: >=20 > Using Google codesearch: interesting results, though the numbers are brittle. I tried to go through the entire result set for Perl f.ex., and on page 2 the number went down from 100 to 50, and on page 3 down further to 45, and stayed there. Still, it=E2=80=99s neat. It=E2=80=99s also interesting to contrast the n= umbers for the MIME type with those for the namespace. > Java:=20 > http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Ajava+application%= 2Fatom%5C%2Bxml&btnG=3DSearch =20 > (50 results) http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Ajava+http%3A%2F%2Fw= ww.w3.org%2F2005%2FAtom&btnG=3DSearch (50 results) > C++:=20 > http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Ac%2B%2B+applicati= on%2Fatom%5C%2Bxml&btnG=3DSearch =20 > (10 results) http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Ac%2B%2B+http%3A%2F%= 2Fwww.w3.org%2F2005%2FAtom&btnG=3DSearch (3 results) > Ruby:=20 > http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Aruby+application%= 2Fatom%5C%2Bxml&btnG=3DSearch =20 > (50 results) http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Aruby+http%3A%2F%2Fw= ww.w3.org%2F2005%2FAtom&btnG=3DSearch (50 results) > Perl:=20 > http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Aperl+application%= 2Fatom%5C%2Bxml&btnG=3DSearch =20 > (100 results) http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Aperl+http%3A%2F%2Fw= ww.w3.org%2F2005%2FAtom&btnG=3DSearch (50 results) > C#:=20 > http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Ac%23+application%= 2Fatom%5C%2Bxml&btnG=3DSearch =20 > (9 results) http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Ac%23+http%3A%2F%2Fw= ww.w3.org%2F2005%2FAtom&btnG=3DSearch (8 results) > Python: > http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Apython+applicatio= n%2Fatom%5C%2Bxml&btnG=3DSearch > (100 results) http://google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Apython+http%3A%2F%2= Fwww.w3.org%2F2005%2FAtom&btnG=3DSearch (50 results) Regards, --=20 Aristotle Pagaltzis // From dgrft44433@yahoo.co.jp Fri Oct 06 01:27:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GViEg-0003Ap-MX for atompub-archive@lists.ietf.org; Fri, 06 Oct 2006 01:27:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GViEg-0002I2-L6 for atompub-archive@lists.ietf.org; Fri, 06 Oct 2006 01:27:02 -0400 Received: from [222.171.146.223] (helo=lists.ietf.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GViEe-0003d4-L3 for atompub-archive@lists.ietf.org; Fri, 06 Oct 2006 01:27:02 -0400 To: From: =?iso-2022-jp?B?GyRCJGokRCQzGyhC?= Subject: =?iso-2022-jp?B?GyRCOnJGfDtkJE4lIiVJJWwlOTA4JEYkSyVhITwlayQsRk8kJCRGJCQkRiEiMDhAaCQsJDMkTiUiJUklbCU5JEskSiRDJEYkJCReJDckPyEjGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 $B%a!<%kAw?.@h$K4V0c$$$"$j$^$;$s$+!)(B $B:rF|;d$N%"%I%l%908$F$K%a!<%k$,FO$$$F$$$F!"08@h$,$3$N%"%I%l%9$K$J$C$F$$$^$7$?!#(B $B;d$O2CG<$H$$$$$^$9!#$I$3$G;d$N%"%I%l%9$rCN$C$?$N$G$7$g$&$+!"7G<(HD$G$7$g$&$+!)(B $B$b$77G<(HD$r8+$F$N%a!<%k$J$i!"=i$a$FD>@\O"Mm$r$b$i$($?$3$H$K$J$j$^$9!#(B $B;d$OITNQ4uK>$J$N$GO"Mm@h$r65$($F$/$l$k?M$,$^$C$?$/$$$^$;$s$G$7$?!#(B $B5.J}$+$i%a!<%k$,Mh$?$H$-$K$O6C$-$^$7$?$1$I!"@5D>4r$7$$5$;}$A$b$"$j$^$7$?!#(B $B7G<(HD$rDL$9;v$GHkL)$r From: =?iso-2022-jp?B?GyRCJGokRCQzGyhC?= Subject: =?iso-2022-jp?B?GyRCOnJGfDtkJE4lIiVJJWwlOTA4JEYkSyVhITwlayQsRk8kJCRGJCQkRiEiMDhAaCQsJDMkTiUiJUklbCU5JEskSiRDJEYkJCReJDckPyEjGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 $B%a!<%kAw?.@h$K4V0c$$$"$j$^$;$s$+!)(B $B:rF|;d$N%"%I%l%908$F$K%a!<%k$,FO$$$F$$$F!"08@h$,$3$N%"%I%l%9$K$J$C$F$$$^$7$?!#(B $B;d$O2CG<$H$$$$$^$9!#$I$3$G;d$N%"%I%l%9$rCN$C$?$N$G$7$g$&$+!"7G<(HD$G$7$g$&$+!)(B $B$b$77G<(HD$r8+$F$N%a!<%k$J$i!"=i$a$FD>@\O"Mm$r$b$i$($?$3$H$K$J$j$^$9!#(B $B;d$OITNQ4uK>$J$N$GO"Mm@h$r65$($F$/$l$k?M$,$^$C$?$/$$$^$;$s$G$7$?!#(B $B5.J}$+$i%a!<%k$,Mh$?$H$-$K$O6C$-$^$7$?$1$I!"@5D>4r$7$$5$;}$A$b$"$j$^$7$?!#(B $B7G<(HD$rDL$9;v$GHkL)$r Date: Sun, 08 Oct 2006 20:20:23 +0100 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: atom-protocol , atom-syntax@imc.org, atom-protocol-python@googlegroups.com Subject: Python implementation of RFC4287, RFC4685 and APP X-Enigmail-Version: 0.94.0.0 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: 8b30eb7682a596edff707698f4a80f7d All, A while ago I had presented atomixlib and amplee, two Python packages to handle teh Atom format and the Atom Pub. protocol. For over a week now I've worked really hard to upgrade both those packages to make them much more useful. atomixlib helps the generation, serialization and deserialization of feed, entry, service documents. Its underlying XMl engines are either Amara or ElementTree (although in its current state the Amara engine is the only one fully implementing the atomixlib API). amplee is a Python library implementing APP so that Python application servers can call it to create, update, delete stores, services, workspaces, members. amplee is based on atomixlib. amplee comes with a set of built-in members to generate entries from audio files such as MP3, Ogg, flac, etc. by extracting their meta-ata (ID3 tags) and filling an Atom entry with those. There is also a built-in member for ODT documents. amplee offers also a couple of built-in backends such as Subversion. More backends will be added soon. Both packages are stable but they lack documentation and aren't fully tested. I therefore don't advise you to try them right now as you may have some issues. I will released stable versions soon but yo ucan have a look in the mean time. http://trac.defuze.org/wiki/atomixlib http://trac.defuze.org/wiki/amplee Hope you will enjoy :) Thanks, - Sylvain From owner-atom-syntax@mail.imc.org Mon Oct 09 11:34:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWx9D-00028K-Cq for atompub-archive@lists.ietf.org; Mon, 09 Oct 2006 11:34:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWx99-0003qS-M0 for atompub-archive@lists.ietf.org; Mon, 09 Oct 2006 11:34:31 -0400 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 k99FIFJ8058162; Mon, 9 Oct 2006 08:18: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 k99FIFmQ058161; Mon, 9 Oct 2006 08:18: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 mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k99FICSR058147 for ; Mon, 9 Oct 2006 08:18:13 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GWwtP-0001ep-9Y; Mon, 09 Oct 2006 17:18:11 +0200 Received: from ultra12.rbg.informatik.tu-darmstadt.de ([130.83.160.102]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.62 #12) id 1GWwtP-0003zw-4y; Mon, 09 Oct 2006 17:18:11 +0200 Message-ID: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> Date: Mon, 09 Oct 2006 17:18:06 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mail/News 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Mark Nottingham CC: Atom-Syntax Syntax Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Mark Nottingham wrote: > I've only had positive comments about -07 so far, so I've recommended it > for publication as a Proposed Standard to the IESG. Congratulations! But while the draft states that "[t]hese [feed] types are complementary" (section 1), but is unfortunately silent on how precisely the three different types can be used together. Here are a few questions I still have: - Is it possible that an Archived Feed Document is marked as complete? How is this to be interpreted? Does each Archive Document represent a snapshot of a previous version of the Complete Feed? (This is the interpretation I lean toward.) - Is it possible that a Paged Feed's pages (i.e., its feed documents) are marked as complete? What does this mean? That the Logical Feed in its entirety, of which each page only contains some entries, is considered to be complete? (I would answer this question with 'yes', but note the resulting difference in semantic between complete Archive Documents and complete pages.) - Is it possible to serve a single, possibly large Archive Document as multiple pages? If so, do there have to be "next" links to the "prev-archive" document, too, or do paging links only cover the current document. (I would prefer the latter interpretation, as illustrated below.) Archive Document 1 ----\ Archive Document 2 ========================= \ ========================= Page 1.1 -next-> Page 1.2 \-prev-archive-> Page 1.1 -next-> Page 1.2 Unfortunately I wasn't able to find the answers to these question in the draft itself; it is silent on the interactions between the three feed types. (In particular, it does not even disallow combining them within a single feed!) So, an explanatory section on the various interactions that might occur is probably a good thing to add. Regards, Andreas From owner-atom-syntax@mail.imc.org Mon Oct 09 13:58:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzOr-0000DC-EA for atompub-archive@lists.ietf.org; Mon, 09 Oct 2006 13:58:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzOp-0003oi-TY for atompub-archive@lists.ietf.org; Mon, 09 Oct 2006 13:58:49 -0400 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 k99HWfV3074190; Mon, 9 Oct 2006 10:32: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 k99HWfoC074189; Mon, 9 Oct 2006 10:32: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k99HWddD074178 for ; Mon, 9 Oct 2006 10:32:40 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nf-out-0910.google.com with SMTP id y38so7063nfb for ; Mon, 09 Oct 2006 10:32:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G3j4D/bJNfZuWPlXyUGe1J55NvDx1BUSm02Lsxp0XIIOmdsLB0NddcnhicqXxHhgKOLDVBpFTWdEhdi2KDAXq99Jqks5IJ05FH02Gm7Wk7rbnadl5Mt8oPtKnDsEshs5vTuxlHdcFmBx2lBVWz2SLnYg2Jz35FiWerm/ZWN5GYU= Received: by 10.48.14.4 with SMTP id 4mr98286nfn; Mon, 09 Oct 2006 10:32:38 -0700 (PDT) Received: by 10.49.28.6 with HTTP; Mon, 9 Oct 2006 10:32:37 -0700 (PDT) Message-ID: Date: Mon, 9 Oct 2006 19:32:37 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 In-Reply-To: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k99HWfdD074183 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 k99HWfV3074190 X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 2006/10/9, Andreas Sewe: > > But while the draft states that "[t]hese [feed] types are complementary= " > (section 1), but is unfortunately silent on how precisely the three > different types can be used together. > > Here are a few questions I still have: > > - Is it possible that an Archived Feed Document is marked as complete? By definition, an Archived Feed is a set of Feed Documents, and an Archive Document is a Feed Document within that set. It cannot be "complete", unless it is the only one in the set, and therefore represents the whole Archived Feed as a single Feed Document. It's "current" link should then point to itself (i.e. the same as the "self" link). > - Is it possible that a Paged Feed's pages (i.e., its feed documents) > are marked as complete? No. By definition, a Complete Feed is a single Feed Document. See: 2. Complete Feeds A complete feed is a feed document that contains all of the entries of a logical feed; any entry not actually in the feed document SHOULD NOT be considered to be part of that feed. > - Is it possible to serve a single, possibly large Archive Document as > multiple pages? Not sure what you're talking about=E2=80=A6 Do you mean a Logical Feed would be split into "stable subsets", each such subset split into "unstable" Feed Documents? In this case, as each document is not "stable", it's a Paged Feed, not an Archived Feed, even if the subset of entries from within 2 Feed Documents form a "stable subset". If every Feed Document is "stable", then you have an Archived Feed an dyou can link Feed Documents to each others using next-archive and prev-archive. --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Tue Oct 10 10:08:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIHN-00027h-C4 for atompub-archive@lists.ietf.org; Tue, 10 Oct 2006 10:08:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXIHL-0005RM-Qj for atompub-archive@lists.ietf.org; Tue, 10 Oct 2006 10:08:21 -0400 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 k9ADo2HC006844; Tue, 10 Oct 2006 06:50: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 k9ADo2P2006843; Tue, 10 Oct 2006 06:50: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9ADnu4u006811 for ; Tue, 10 Oct 2006 06:50:01 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GXHzW-0003k5-It; Tue, 10 Oct 2006 15:49:54 +0200 Received: from ultra16.rbg.informatik.tu-darmstadt.de ([130.83.160.106]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.62 #12) id 1GXHzW-0003FG-A7; Tue, 10 Oct 2006 15:49:54 +0200 Message-ID: <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> Date: Tue, 10 Oct 2006 15:49:45 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mail/News 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Thomas Broyer CC: Atom Syntax , Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Thomas Broyer wrote: > 2006/10/9, Andreas Sewe: >> But while the draft states that "[t]hese [feed] types are complementary" >> (section 1), but is unfortunately silent on how precisely the three >> different types can be used together. >> >> Here are a few questions I still have: >> >> - Is it possible that an Archived Feed Document is marked as complete? > > By definition, an Archived Feed is a set of Feed Documents, and an > Archive Document is a Feed Document within that set. It cannot be > "complete", unless it is the only one in the set, and therefore > represents the whole Archived Feed as a single Feed Document. It's > "current" link should then point to itself (i.e. the same as the > "self" link). Thank you for the clarification; I did not get my terminology straight. But it would be desirable, IMHO, to be able to link to archived, older versions of a complete feed from within the current complete feed document. Say, a feed document contains this month's Top Ten. Wouldn't it be nice if the feed document could link to September's Top Ten, in case anybody is interested in all the recent Top Ten lists? And linking to archived feed documents is precisely what "prev-archive" and "next-archive" are for. So why can't I use them in conjunction with complete feeds? >> - Is it possible that a Paged Feed's pages (i.e., its feed documents) >> are marked as complete? > > No. By definition, a Complete Feed is a single Feed Document. > > See: > 2. Complete Feeds > > A complete feed is a feed document that contains all of the entries > of a logical feed; any entry not actually in the feed document SHOULD > NOT be considered to be part of that feed. This is the same reason as to why archived feeds can't be complete. But, as I argued above, making an archive of complete feed documents available ought to be possible with archived feeds, too. Now, in contrast to archived feeds, paged feeds serve a different purpose: they allow a logical feed to be divided into more easily digestible pages. (See the APP draft: "A naive client such as a web spider or web browser could be overwhelmed if the response to a GET contained every entry in the Collection, and the server would waste large amounts of bandwidth and processing time on clients unable to handle the response.") And I can't think of a reason why complete feeds are per se small enough to be served without problems as a single document. Granted, the above Top Ten list example contains, in all likelihood, only ten entries, but what about Top 100s, the Supercomputing Top 500, etc.? If you accept the usefulness of complete paged or archive feeds for a moment, you will see that "completeness" should extend from one page to the next (or previous), but not from one archive document to another; each archive document is considered complete in its own right. >> - Is it possible to serve a single, possibly large Archive Document as >> multiple pages? > > Not sure what you're talking about... > > Do you mean a Logical Feed would be split into "stable subsets", each > such subset split into "unstable" Feed Documents? > In this case, as each document is not "stable", it's a Paged Feed, not > an Archived Feed, even if the subset of entries from within 2 Feed > Documents form a "stable subset". > If every Feed Document is "stable", then you have an Archived Feed an > dyou can link Feed Documents to each others using next-archive and > prev-archive. This was more or less what I was getting at, and while I recognize the issue of stability, being able to page an archive document does make sense if you follow the above analysis: 1) archival of complete feeds is useful (each archive document will be marked as complete) and 2) even complete feeds may need to be paged (each complete archive document might be served as several pages). Putting it all together this leads to a variant of the diagram in my previous mail: Compl. Archive Document 1 -\ Compl. Archive Document 2 ========================= \ ========================= Page 1.1 -next-> Page 1.2 \-prev-archive-> Page 1.1 -next-> Page 1.2 Here Archive Document 1 contains, say, last month's Top 100 as a complete archive document split into two pages of 50 entries each. It then links, via "prev-archive", to August's Top 100 which is again split in two. Does this explanation make sense? I am aware, now, that this is not what the current draft says, since the three types of feed (complete, paged, and archived feed) can't be combined in *any* way, even though the draft's introduction claims that "[t]hese types are complementary". But at least some of the additional expressiveness offered by the combination of complete with either paged or archive feeds would be nice to have -- even though it adds some minor complexities. Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Thu Oct 12 00:56:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXscF-0002VA-O7 for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 00:56:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXscB-0004wm-8k for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 00:56:19 -0400 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 k9C4U8u9019070; Wed, 11 Oct 2006 21:30: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 k9C4U8hf019069; Wed, 11 Oct 2006 21:30: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 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 k9C4U7Bf019057 for ; Wed, 11 Oct 2006 21:30:07 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.3] (unknown [216.145.49.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 615E95193B for ; Thu, 12 Oct 2006 00:30:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B984396-6F4A-4E54-BCAF-0CEAA448491C@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Wed, 11 Oct 2006 21:29:27 -0700 To: Atom-Syntax Syntax X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 I've had a private request to add elements to optionally indicate: a) how many pages there are in total, and b) what the current page number is in the case of paged feeds. What do people think? I note that OpenSearch has something along these lines (sort of) already: http://www.opensearch.org/Specifications/OpenSearch/1.1#The_. 22totalResults.22_element Cheers, On 2006/10/04, at 11:13 AM, Mark Nottingham wrote: > > I've only had positive comments about -07 so far, so I've > recommended it for publication as a Proposed Standard to the IESG. > > As part of that process, I'm issuing an informal, pseudo-WG Last > Call on the document to capture any remaining feedback. In particular, > > * What do people think about putting this document on the Standards > Track? > > * Do you have an implementation available, in progress, planned, etc.? > > http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed- > history/ > > Please provide feedback by October 18th. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Oct 12 01:00:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXsgJ-0005AW-8u for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 01:00:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXsgH-0005JE-I9 for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 01:00:31 -0400 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 k9C4Ww4g019413; Wed, 11 Oct 2006 21:32: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 k9C4Ww2F019410; Wed, 11 Oct 2006 21:32: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 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 k9C4WvC8019396 for ; Wed, 11 Oct 2006 21:32:57 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.3] (unknown [216.145.49.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 00B0951943; Thu, 12 Oct 2006 00:32:55 -0400 (EDT) In-Reply-To: <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> Cc: Thomas Broyer , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Wed, 11 Oct 2006 21:32:21 -0700 To: Andreas Sewe X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 On 2006/10/10, at 6:49 AM, Andreas Sewe wrote: > Thomas Broyer wrote: >> 2006/10/9, Andreas Sewe: >>> But while the draft states that "[t]hese [feed] types are >>> complementary" >>> (section 1), but is unfortunately silent on how precisely the three >>> different types can be used together. >>> >>> Here are a few questions I still have: >>> >>> - Is it possible that an Archived Feed Document is marked as >>> complete? >> By definition, an Archived Feed is a set of Feed Documents, and an >> Archive Document is a Feed Document within that set. It cannot be >> "complete", unless it is the only one in the set, and therefore >> represents the whole Archived Feed as a single Feed Document. It's >> "current" link should then point to itself (i.e. the same as the >> "self" link). > > Thank you for the clarification; I did not get my terminology > straight. > > But it would be desirable, IMHO, to be able to link to archived, > older versions of a complete feed from within the current complete > feed document. > > Say, a feed document contains this month's Top Ten. Wouldn't it be > nice if the feed document could link to September's Top Ten, in > case anybody is interested in all the recent Top Ten lists? And > linking to archived feed documents is precisely what "prev-archive" > and "next-archive" are for. So why can't I use them in conjunction > with complete feeds? I think you're trying to reconstruct a different dimension; archived feeds, when reconstructed, contain only entries that are currently considered members of the feed; what you want to do is to have snapshots of the feed's members over time, separate from what the current members are. This might work as a "prev-version" link relation... >>> - Is it possible that a Paged Feed's pages (i.e., its feed >>> documents) >>> are marked as complete? >> No. By definition, a Complete Feed is a single Feed Document. >> See: >> 2. Complete Feeds >> A complete feed is a feed document that contains all of the entries >> of a logical feed; any entry not actually in the feed document >> SHOULD >> NOT be considered to be part of that feed. > > This is the same reason as to why archived feeds can't be complete. > But, as I argued above, making an archive of complete feed > documents available ought to be possible with archived feeds, too. > > Now, in contrast to archived feeds, paged feeds serve a different > purpose: they allow a logical feed to be divided into more easily > digestible pages. (See the APP draft: "A naive client such as a web > spider or web browser could be overwhelmed if the response to a GET > contained every entry in the Collection, and the server would waste > large amounts of bandwidth and processing time on clients unable to > handle the response.") > > And I can't think of a reason why complete feeds are per se small > enough to be served without problems as a single document. Granted, > the above Top Ten list example contains, in all likelihood, only > ten entries, but what about Top 100s, the Supercomputing Top 500, > etc.? It isn't a complete feed, then. Completeness is defined as having all of the entries in one physical document. >>> >>> >>> - Is it possible to serve a single, possibly large Archive >>> Document as >>> multiple pages? >> Not sure what you're talking about... > > >> Do you mean a Logical Feed would be split into "stable subsets", each >> such subset split into "unstable" Feed Documents? >> In this case, as each document is not "stable", it's a Paged Feed, >> not >> an Archived Feed, even if the subset of entries from within 2 Feed >> Documents form a "stable subset". >> If every Feed Document is "stable", then you have an Archived Feed an >> dyou can link Feed Documents to each others using next-archive and >> prev-archive. > > This was more or less what I was getting at, and while I recognize > the issue of stability, being able to page an archive document does > make sense if you follow the above analysis: 1) archival of > complete feeds is useful (each archive document will be marked as > complete) and 2) even complete feeds may need to be paged (each > complete archive document might be served as several pages). > > Putting it all together this leads to a variant of the diagram in > my previous mail: > > Compl. Archive Document 1 -\ Compl. Archive > Document 2 > ========================= \ > ========================= > Page 1.1 -next-> Page 1.2 \-prev-archive-> Page 1.1 -next-> Page > 1.2 > > Here Archive Document 1 contains, say, last month's Top 100 as a > complete archive document split into two pages of 50 entries each. > It then links, via "prev-archive", to August's Top 100 which is > again split in two. > > Does this explanation make sense? > > I am aware, now, that this is not what the current draft says, > since the three types of feed (complete, paged, and archived feed) > can't be combined in *any* way, even though the draft's > introduction claims that "[t]hese types are complementary". But at > least some of the additional expressiveness offered by the > combination of complete with either paged or archive feeds would be > nice to have -- even though it adds some minor complexities. My gut feeling is that while there might be some use cases for this sort of thing, it's going beyond the 80/20 point, and adding a lot of complexity/abstraction. When I said that they were complementary, I meant that together, they cover most feeds in common use today, not that they can be used together. I do want to address the combination issue, however. I'm inclined to just state that the semantics of feeds that have more than one type is undefined by this spec. Does that work for you? Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Oct 12 01:22:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXt1c-0006xX-QK for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 01:22:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXt1b-0007q0-8x for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 01:22:32 -0400 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 k9C575iH022881; Wed, 11 Oct 2006 22:07: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 k9C575Js022880; Wed, 11 Oct 2006 22:07:05 -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 k9C5745M022871 for ; Wed, 11 Oct 2006 22:07:05 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.3] (unknown [216.145.49.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 8D3F551943; Thu, 12 Oct 2006 01:07:03 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A4EE4AB-6187-4FF9-AB03-71320C473BB7@mnot.net> Cc: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Wed, 11 Oct 2006 22:06:28 -0700 To: David Hall X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 On 2006/10/05, at 12:55 PM, David Hall wrote: > > Hey Mark - > > Things are looking good to me. > > Couple questions, comments: > > 1. I think your document might need to address what's supposed to > happen > if duplicate items are discovered when trolling through the paged > info. > Newer replaces older? (That makes the most sense to me) Although I > guess > the argument might be, "what's an 'item'?". I started going down that road in early drafts, but backed away from it when it started looking like a rat hole. :) To allow FH to normatively specify what to do with duplicates, you have to figure out the ordering of entries, so you can determine their relative precedence. Since Atom doesn't have any explicit ordering, FH would need to either assume ordering semantics implicitly, or doing something explicit in an extension. In the paged case, this seems like a tall order, because it's totally context-dependent; e.g., if you have OpenSearch or GData results, or orders for launching the missiles that are paged, and you happen to get a duplicate, the right thing to do may be very different. In the archived case, it's a little easier, because we're already inferring that the pages closes to current do have precedence, so we just need to figure out what to do about duplicates in the same feed document. I could see making the implied page-by-page precedence for Archived feeds in section 4 explicit. It would also be easy to add text saying that relative precedence in the same feed document can be determined by any extension that defines ordering, defaulting to the update time of the entries (or document order, topmost first? I think this is what most people do, but it seems contrary to the spirit of the Atom spec). I'm not crazy about actually defining an ordering extension (is one in progress? James?) in FH. Does that work for you? > 2. We're currently recommending 'feed history' as a best practice for > Media RSS. http://search.yahoo.com/mrss > > (I'll need to update that link in the documentation) Thanks! > > Thanks- > David > >> From: Mark Nottingham >> Date: 4 October 2006 11:13:06 AM >> To: Atom-Syntax Syntax >> Subject: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 >> >> >> I've only had positive comments about -07 so far, so I've >> recommended it for publication as a Proposed Standard to the IESG. >> >> As part of that process, I'm issuing an informal, pseudo-WG Last >> Call on the document to capture any remaining feedback. In >> particular, >> >> * What do people think about putting this document on the Standards >> Track? >> >> * Do you have an implementation available, in progress, planned, >> etc.? >> >> http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed- >> history/ >> >> Please provide feedback by October 18th. >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Oct 12 03:12:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXujt-00059E-0q for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 03:12:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXujp-0004EF-FJ for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 03:12:21 -0400 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 k9C6q3wx038173; Wed, 11 Oct 2006 23:52: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 k9C6q3bZ038172; Wed, 11 Oct 2006 23:52: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9C6q1kH038166 for ; Wed, 11 Oct 2006 23:52:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id y38so997506nfb for ; Wed, 11 Oct 2006 23:52:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=up2lmXvEwmCpYOp+CB77Ky+lB3IdGLHBnIBM9bCYadB7XShWqmXNynWH1VFYYL0gG0/H2TewQYM4egw+uPUWEWi1NOaVsNKwynJcwJPVrqsZzbeoXeIy75ajcySlPfY4+zrzIWcwQ9ntSwTP1y1AsbqIuoBmDXJ552Gi+iTy9Q8= Received: by 10.78.97.7 with SMTP id u7mr1841932hub; Wed, 11 Oct 2006 23:52:00 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.google.com with ESMTP id 30sm2103665hub.2006.10.11.23.51.57; Wed, 11 Oct 2006 23:51:58 -0700 (PDT) Message-ID: <452DE609.3080102@gmail.com> Date: Wed, 11 Oct 2006 23:51:53 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Mark Nottingham CC: Atom-Syntax Syntax Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: <7B984396-6F4A-4E54-BCAF-0CEAA448491C@mnot.net> In-Reply-To: <7B984396-6F4A-4E54-BCAF-0CEAA448491C@mnot.net> 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: 1.1 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 -1. I don't think these would buy us anything we can't already easily get from OpenSearch. Mark Nottingham wrote: > > I've had a private request to add elements to optionally indicate: > a) how many pages there are in total, and > b) what the current page number is > in the case of paged feeds. > > What do people think? I note that OpenSearch has something along these > lines (sort of) already: > > http://www.opensearch.org/Specifications/OpenSearch/1.1#The_.22totalResults.22_element > > > Cheers, > > > On 2006/10/04, at 11:13 AM, Mark Nottingham wrote: > >> >> I've only had positive comments about -07 so far, so I've recommended >> it for publication as a Proposed Standard to the IESG. >> >> As part of that process, I'm issuing an informal, pseudo-WG Last Call >> on the document to capture any remaining feedback. In particular, >> >> * What do people think about putting this document on the Standards >> Track? >> >> * Do you have an implementation available, in progress, planned, etc.? >> >> http://ietfreport.isoc.org/idref/draft-nottingham-atompub-feed-history/ >> >> Please provide feedback by October 18th. >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Thu Oct 12 05:59:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxLw-0005w0-RL for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 05:59:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxLv-0006ii-A5 for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 05:59:48 -0400 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 k9C9gZoe062692; Thu, 12 Oct 2006 02:42: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 k9C9gZkW062691; Thu, 12 Oct 2006 02:42: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9C9gXG6062666 for ; Thu, 12 Oct 2006 02:42:34 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GXx5E-0008CC-4e; Thu, 12 Oct 2006 11:42:32 +0200 Received: from ultra16.rbg.informatik.tu-darmstadt.de ([130.83.160.106]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.62 #12) id 1GXx5E-0000KV-0m; Thu, 12 Oct 2006 11:42:32 +0200 Message-ID: <452E0DFD.6010204@rbg.informatik.tu-darmstadt.de> Date: Thu, 12 Oct 2006 11:42:21 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mail/News 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Mark Nottingham CC: Atom Syntax Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> In-Reply-To: <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Mark Nottingham wrote: > Andreas Sewe wrote: >> But it would be desirable, IMHO, to be able to link to archived, older >> versions of a complete feed from within the current complete feed >> document. >> >> Say, a feed document contains this month's Top Ten. Wouldn't it be >> nice if the feed document could link to September's Top Ten, in case >> anybody is interested in all the recent Top Ten lists? And linking to >> archived feed documents is precisely what "prev-archive" and >> "next-archive" are for. So why can't I use them in conjunction with >> complete feeds? > > I think you're trying to reconstruct a different dimension; archived > feeds, when reconstructed, contain only entries that are currently > considered members of the feed; what you want to do is to have snapshots > of the feed's members over time, separate from what the current members > are. Right. The point is that for non-complete feeds members are only ever added (never removed) as time goes by. Hence you can reconstruct a previous revision of an Archived Feed simply by following the "prev-archive" links far enough into the past; so there is, for non-complete Archived Feeds, no real need for another link relation to cover this dimension: > This might work as a "prev-version" link relation... Now there are already "previous" and "prev-archive"; do we really need "prev-version" to cover the case of Complete Feeds? At least for non-complete Archived Feeds it is not really needed, which gives me the gut feeling that "prev-version" might not be needed for Complete Feeds either. (Unfortunately, I cannot come up with a satisfactory definition for "prev-archive" that would work for both cases, complete and non-complete. But that does not mean there is none...) (For the moment, the "related" link relation with an explanatory @title will do.) >> I am aware, now, that this is not what the current draft says, since >> the three types of feed (complete, paged, and archived feed) can't be >> combined in *any* way, even though the draft's introduction claims >> that "[t]hese types are complementary". But at least some of the >> additional expressiveness offered by the combination of complete with >> either paged or archive feeds would be nice to have -- even though it >> adds some minor complexities. > > My gut feeling is that while there might be some use cases for this sort > of thing, it's going beyond the 80/20 point, and adding a lot of > complexity/abstraction. When I said that they were complementary, I > meant that together, they cover most feeds in common use today, not that > they can be used together. I see. Maybe it would be a good idea to spell this out explicitly in the spec, even if the "Completeness is defined as having all of the entries in one physical document" condition implies it. That way you can be sure that everyone, me included, gets the semantics right. (FWIW, nothing prevents stable logical feeds from being both Archived and Paged Feeds, right? Only unstable feeds can just be Paged, not Archived.) > I do want to address the combination issue, however. I'm inclined to > just state that the semantics of feeds that have more than one type is > undefined by this spec. Does that work for you? It does. It would be worthwhile, however, to state that a future revision of your spec might choose to define behavior for these cases. (None of the features I have proposed would contradict the current semantics of Complete, Paged, and Archived Feeds.) Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Thu Oct 12 13:15:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY49a-00020K-Hm for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 13:15:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY49W-0007Lv-2i for atompub-archive@lists.ietf.org; Thu, 12 Oct 2006 13:15:30 -0400 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 k9CGfSC4014500; Thu, 12 Oct 2006 09:41: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 k9CGfShM014499; Thu, 12 Oct 2006 09:41: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 wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9CGfQep014493 for ; Thu, 12 Oct 2006 09:41:27 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so146981wri for ; Thu, 12 Oct 2006 09:41:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=MkpMROuoUtxSyqdP3/NcHP91e6Fbaa0eAiA0b2oOvOap/UnumgnhYOMYlRcY/5+x+2wo0tDnG5tXqrA70EqihTKSx4GZ9x+8wvUukxr9C9tg4DehGDktKUlvst3HyrB6lycIiAvh14m3DluJytT6ZFYqltInJHCBQE4VVm3Vp+c= Received: by 10.90.80.8 with SMTP id d8mr1490773agb; Thu, 12 Oct 2006 09:41:26 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.google.com with ESMTP id g9sm1038202wra.2006.10.12.09.41.25; Thu, 12 Oct 2006 09:41:25 -0700 (PDT) Message-ID: <452E7032.1030101@gmail.com> Date: Thu, 12 Oct 2006 09:41:22 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax Subject: New version of License Draft 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: 4d87d2aa806f79fed918a62e834505ca Following the round of last-call comments, I have published an update to the Feed license draft. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-09.txt There are a number of important changes: * License links in feeds are now inherited by entries If an entry element does not contain a "license" link relation, then the "license" link relation of the containing feed or contained source element, if present, is considered to apply to the entry. This has been the most debated aspect of this draft and I know there are folks who will disagree with this decision. However, the majority of folks who took the time to comment on this favored an inheritance model similar to that used by the atom:rights element. * I've introduced an "unspecified license link". This is a special href attribute value that can be used to indicate that a license has not been explicitly associated with a feed or entry. This is particularly useful for republishers and aggregators who wish to indicate whether or not the entries they are republishing originally had license links, e.g., ... ... ... ... The presence of a unspecified license link does not mean that the entry doesn't have a license, just that the license has not been specified. * I've clarified that the license link is intended only to provide a potentially machine readable description of explicit rights that have been granted for a resource. I have requested that Lisa reissue the Last-Call on this. As always, additional comments and feedback are requested and welcomed. - James From owner-atom-syntax@mail.imc.org Fri Oct 13 16:48:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTxD-0004oW-Cf for atompub-archive@lists.ietf.org; Fri, 13 Oct 2006 16:48:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYTxB-0007ap-VJ for atompub-archive@lists.ietf.org; Fri, 13 Oct 2006 16:48:27 -0400 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 k9DKKaIa057822; Fri, 13 Oct 2006 13:20: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 k9DKKaMx057821; Fri, 13 Oct 2006 13:20: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9DKKZSo057815 for ; Fri, 13 Oct 2006 13:20:36 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so1078094wxc for ; Fri, 13 Oct 2006 13:20:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=eKjorEeVv9Pam4q+qnBtFZj/rcNbi3fUfs/7KKxBJuUJMlfN1D9Xu1AsVeUPWehovTwJH2leORY5pUKa8G4DqQq+yipU54ZYCQceZfUkON4btuRSKR6k/VHk2bAslrwbOSelcashPv3x3I4vKCkXpf/qfCoot0aJ+xjldFJGmDc= Received: by 10.90.78.9 with SMTP id a9mr2797988agb; Fri, 13 Oct 2006 13:20:34 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm1517594wrl.2006.10.13.13.20.33; Fri, 13 Oct 2006 13:20:34 -0700 (PDT) Message-ID: <452FF50C.9040901@gmail.com> Date: Fri, 13 Oct 2006 13:20:28 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax Subject: Atom bidi 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: e8a67952aa972b528dd04570d58ad8fe As an alternative to adding the dir attribute to rfc4287, I've published draft-snell-atompub-bidi-00.txt as an extension in a separate namespace. As always, feedback is requested and welcome. - James -------- Original Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Atom Bidirectional Extension Author(s) : J. Snell Filename : draft-snell-atompub-bidi-00.txt Pages : 8 Date : 2006-10-13 This document describes an extension to the Atom format that can be used to define the base directionality of directionally-neutral characters contained within an Atom document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-snell-atompub-bidi-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-snell-atompub-bidi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-atom-syntax@mail.imc.org Mon Oct 16 13:51:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWcg-00006n-2k for atompub-archive@lists.ietf.org; Mon, 16 Oct 2006 13:51:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWVX-0000IF-9c for atompub-archive@lists.ietf.org; Mon, 16 Oct 2006 13:44:12 -0400 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 k9GH7Paw092190; Mon, 16 Oct 2006 10:07: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 k9GH7PeB092189; Mon, 16 Oct 2006 10:07: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 ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9GH7OgF092176 for ; Mon, 16 Oct 2006 10:07:24 -0700 (MST) (envelope-from mirror@ietf.org) Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 91CFB175A0; Mon, 16 Oct 2006 17:07:18 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GZVvq-0006Ib-5K; Mon, 16 Oct 2006 13:07:18 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Robert Sayre Cc: ietf-announce@ietf.org, atom-syntax@imc.org From: IESG Secretary Subject: Response to appeal by Robert Sayre dated 2006-08-29 Message-Id: Date: Mon, 16 Oct 2006 13:07:18 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is the IESG response to the appeal by Robert Sayre posted at http://www.ietf.org/IESG/APPEALS/appeal-from-robert-sayre-08-29-2006.txt. The IESG has considered Mr. Sayre's concerns and believes that by requiring mandatory to implement security mechanisms the IESG is continuing a long established practice with strong IETF-wide community support. Acting counter to that support would require evidence of a new community consensus. Some sparse recent discussion on the IETF-wide list has not yet shown a change in this support. Therefore, we reject the appeal and hold with our original advice given to the atompub working group. --------- Appendix: Summary of relevant IETF documents RFC 3935 (BCP 95) states "The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users." RFC 2026 (BCP9) requires demonstrated interoperability of all features (mandatory or optional) prior to advancement to DS. Although demonstrated interoperability is not required for PS, it is clearly illogical to admit a spec to the standards track that is by construction ineligible for DS. Therefore, interoperability is the overall goal and all features (mandatory or optional) must be designed to be interoperable. RFC 2360 (BCP 22) points out the dangers of optional features: "2.10 Handling of Protocol Options Specifications with many optional features increase the complexity of the implementation and the chance of non-interoperable implementations. The danger is that different implementations may specify some combination of options that are unable to interoperate with each other." RFC 3365 (BCP 61) requires strong security to be available for all protocols. "The solution is that we MUST implement strong security in all protocols to provide for the all too frequent day when the protocol comes into widespread use in the global Internet. ... However security must be a MUST IMPLEMENT so that end users will have the option of enabling it when the situation calls for it." RFC 3631 (IAB document), section 2.2, discusses "Mandatory to implement" security in more detail. The key sentence is "To solve this problem, the IETF requires that *ALL* protocols provide appropriate security mechanisms, even when their domain of application is at first believed to be very limited." This is an IAB document, not a BCP, but it is a document that was discussed widely prior to publication. It describes the policy followed by the IESG for many years and endorsed by the IAB, in tandem with BCP 61. --- From owner-atom-syntax@mail.imc.org Mon Oct 16 15:13:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXtn-0005Yt-RZ for atompub-archive@lists.ietf.org; Mon, 16 Oct 2006 15:13:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXtm-0006uz-GF for atompub-archive@lists.ietf.org; Mon, 16 Oct 2006 15:13:19 -0400 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 k9GIl3Mr002525; Mon, 16 Oct 2006 11: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 k9GIl3GX002524; Mon, 16 Oct 2006 11: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9GIl13H002513 for ; Mon, 16 Oct 2006 11:47:02 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 16 Oct 2006 18:46:55 -0000 Received: from p508F9D06.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.157.6] by mail.gmx.net (mp019) with SMTP; 16 Oct 2006 20:46:55 +0200 X-Authenticated: #1915285 Message-ID: <4533D39A.9040307@gmx.de> Date: Mon, 16 Oct 2006 20:46:50 +0200 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: IESG Secretary CC: Robert Sayre , atom-syntax@imc.org Subject: Re: Response to appeal by Robert Sayre dated 2006-08-29 References: 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: 856eb5f76e7a34990d1d457d8e8e5b7f Well. Could the IESG then please answer the following simple question...? "If HTTP/1.1 (as defined in RFC2616) would be submitted today for publication as Proposed Standard, would it be accepted?" If no, shouldn't the IESG revoke the current status of "Draft Standard", and declare it as "historic" (as per RFC2026, Section 6.2)? (that is, the documented standards process clearly isn't the *current* standards process, thus it seems funny to me that the IESG claims BCPs to be the last word when in fact one of the most successful protocols on this planet doesn't comply to them). Best regards, Julian From owner-atom-syntax@mail.imc.org Mon Oct 16 19:20:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZbkh-0000BC-CO for atompub-archive@lists.ietf.org; Mon, 16 Oct 2006 19:20:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZbkf-0002Qu-Qb for atompub-archive@lists.ietf.org; Mon, 16 Oct 2006 19:20:11 -0400 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 k9GMiNEm020734; Mon, 16 Oct 2006 15:44: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 k9GMiNZ5020733; Mon, 16 Oct 2006 15:44: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 ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9GMiLoV020725 for ; Mon, 16 Oct 2006 15:44:22 -0700 (MST) (envelope-from iesg-secretary@ietf.org) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9GMiCLl024602; Mon, 16 Oct 2006 17:44:19 -0500 (CDT) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.7]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Oct 2006 16:48:57 -0500 Received: from mail pickup service by ILEXC1U01.ndc.lucent.com with Microsoft SMTPSVC; Mon, 16 Oct 2006 16:48:56 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ILEXC1U01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Oct 2006 12:14:55 -0500 Received: from horh1.emsr.lucent.com ([135.112.138.211]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Oct 2006 12:16:32 -0500 Received: from ihemail3.lucent.com (ihemail3.dmz.lucent.com [135.245.2.37]) by horh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id k9GHG2s1001768 for ; Mon, 16 Oct 2006 12:16:32 -0500 (CDT) Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145]) by ihemail3.lucent.com (8.13.8/IER-i) with ESMTP id k9GHG1Wq024910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Oct 2006 12:16:01 -0500 (CDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVwM-0002Gg-HQ; Mon, 16 Oct 2006 13:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVwL-0002Gb-BA for ietf-announce@ietf.org; Mon, 16 Oct 2006 13:07:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVwL-0001A6-7L for ietf-announce@ietf.org; Mon, 16 Oct 2006 13:07:49 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZVwK-0001MS-SO for ietf-announce@ietf.org; Mon, 16 Oct 2006 13:07:49 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 91CFB175A0; Mon, 16 Oct 2006 17:07:18 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GZVvq-0006Ib-5K; Mon, 16 Oct 2006 13:07:18 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Robert Sayre From: IESG Secretary Message-Id: Date: Mon, 16 Oct 2006 13:07:18 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: atom-syntax@imc.org, ietf-announce@ietf.org Subject: Response to appeal by Robert Sayre dated 2006-08-29 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 16 Oct 2006 17:16:33.0094 (UTC) FILETIME=[D3DA4660:01C6F146] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is the IESG response to the appeal by Robert Sayre posted at http://www.ietf.org/IESG/APPEALS/appeal-from-robert-sayre-08-29-2006.txt. The IESG has considered Mr. Sayre's concerns and believes that by requiring mandatory to implement security mechanisms the IESG is continuing a long established practice with strong IETF-wide community support. Acting counter to that support would require evidence of a new community consensus. Some sparse recent discussion on the IETF-wide list has not yet shown a change in this support. Therefore, we reject the appeal and hold with our original advice given to the atompub working group. --------- Appendix: Summary of relevant IETF documents RFC 3935 (BCP 95) states "The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users." RFC 2026 (BCP9) requires demonstrated interoperability of all features (mandatory or optional) prior to advancement to DS. Although demonstrated interoperability is not required for PS, it is clearly illogical to admit a spec to the standards track that is by construction ineligible for DS. Therefore, interoperability is the overall goal and all features (mandatory or optional) must be designed to be interoperable. RFC 2360 (BCP 22) points out the dangers of optional features: "2.10 Handling of Protocol Options Specifications with many optional features increase the complexity of the implementation and the chance of non-interoperable implementations. The danger is that different implementations may specify some combination of options that are unable to interoperate with each other." RFC 3365 (BCP 61) requires strong security to be available for all protocols. "The solution is that we MUST implement strong security in all protocols to provide for the all too frequent day when the protocol comes into widespread use in the global Internet. .. However security must be a MUST IMPLEMENT so that end users will have the option of enabling it when the situation calls for it." RFC 3631 (IAB document), section 2.2, discusses "Mandatory to implement" security in more detail. The key sentence is "To solve this problem, the IETF requires that *ALL* protocols provide appropriate security mechanisms, even when their domain of application is at first believed to be very limited." This is an IAB document, not a BCP, but it is a document that was discussed widely prior to publication. It describes the policy followed by the IESG for many years and endorsed by the IAB, in tandem with BCP 61. --- _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-atom-syntax@mail.imc.org Tue Oct 17 08:17:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnss-0003IT-1y for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 08:17:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnjb-0002lc-Mq for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 08:07:54 -0400 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 k9HBkk0x088073; Tue, 17 Oct 2006 04:46: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 k9HBkk85088072; Tue, 17 Oct 2006 04:46: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.internode.on.net (bld-mail01.adl2.internode.on.net [203.16.214.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HBkiG7088048 for ; Tue, 17 Oct 2006 04:46:45 -0700 (MST) (envelope-from arsptr@internode.on.net) Received: from [192.168.1.3] (unverified [59.167.4.175]) by mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 240853618 for multiple; Tue, 17 Oct 2006 21:16:37 +0930 (CST) In-Reply-To: <4523CE66.4070204@gmail.com> References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Elliotte Harold , Bill de hOra , atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Alastair Rankine Subject: Re: Atom Export Date: Tue, 17 Oct 2006 21:46:36 +1000 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 On 05/10/2006, at 1:08 AM, James M Snell wrote: >> 1. Complete list of authors and categories defined > > With permissions, metadata, etc. Metadata like URL and email, sure. I'm not so sure about permissions. Do we do groups then? And do we try to represent permissions for actions that are not directly related to authoring content? (eg changing the theme) There is huge potential for scope creep here. My intent with an Atom-based export file format is to facilitate migration from one blogging engine (or similar CMS) to another. But implementations will differ in the functions they offer, and the way they offer them, so it is unreasonable I think to expect that a single file format would allow seamless migration in all cases. Such a format would be a union of the collective data models of all current and future blogging engines, and hence doomed to unimplementable complexity. So there is a compromise to be made here: on the one hand we want the exported file to contain as much important data as possible, but on the other hand the format needs to be simple enough to implement across multiple blogging engines. I think it's a worthy goal to minimize, rather than eliminate, the amount of manual reworking required when migrating from one platform to another. In other words it is not a goal for this format to be suitable for backup/restore. All this is a roundabout way of saying that each blogging engine is likely to have a unique permissions model, and that it is not a big win to attempt to represent this in the export file format. > I would add to this information about what plugins have been > applied and > what templates have been used. These, of course, are not going to be > portable to different blog environments but the information would be > necessary in order to faithfully recreate the entries later. Agree, but there is a minefield of complexity here. I currently use Typo as a blogging engine and it supports macros and filters in addition to a set of basic markup langauges. Getting the right combination of macros and filters is important to producing correct HTML output. So it would seem pretty important to include this information in the export file. But on the other hand the macros and filters are unlikely to be supported on other platform, so probably the safest course of action is to expand these when the content is exported? There is some loss of information here, and an export/import operation is no longer semantically neutral, but the alternative is potentially worse. >> The tricky bit is defining what is meant by "owned" media. > > I would say that it's any media linked to by an entry located on the > same host as the entry, with the exporter given some discretion as to > what to include and what not to include. Agree. In practice the decision is likely to be based on whether the exporter can find the linked media file on a local filesystem. Each image included probably needs to be accompanied by the (relative?) URL at which it was originally published. So the list is now: 1. Complete list of authors defined. For each author: a. Name b. URI c. email 2. Complete list of categories defined: a. Name b. URI 3. All articles. For each article: a. Source text b. All the relevant metadata from the Atom spec, namely: author, ID, published, rights, title, updated, summary, categories c. Some other metadata: draft status, syntax of source 4. All comments and trackbacks. For each comment or trackback: a. Source text b. Atom spec metadata: author, ID, title, published, summary, avatar? c. Additional metadata: pointer to parent article or comment (ie "in-reply-to") 5. All "Owned" media. For each media object: a. URI b. MIME type c. Binary data Does this look about right? Obviously there would need to be a liberal sprinkling of extension points for proprietary information. From owner-atom-syntax@mail.imc.org Tue Oct 17 08:46:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoLR-0001St-Eq for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 08:46:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZoLM-0002f1-W4 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 08:46:57 -0400 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 k9HCQBjN092443; Tue, 17 Oct 2006 05:26: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 k9HCQBiZ092442; Tue, 17 Oct 2006 05:26: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9HCQ9w6092427 for ; Tue, 17 Oct 2006 05:26:10 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 Oct 2006 12:26:03 -0000 Received: from xdsl-213-196-225-211.netcologne.de (EHLO klangraum) [213.196.225.211] by mail.gmx.net (mp035) with SMTP; 17 Oct 2006 14:26:03 +0200 X-Authenticated: #163624 Date: Tue, 17 Oct 2006 14:26:03 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Atom Export Message-ID: <20061017122603.GD26771@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4523CE66.4070204@gmail.com> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k9HCQBjN092443 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * James M Snell [2006-10-04 17:30]: > I would add to this information about what plugins have been > applied and what templates have been used. These, of course, > are not going to be portable to different blog environments but > the information would be necessary in order to faithfully > recreate the entries later. -1 These should be engine-specific extensions. The format should be broad enough in scope that it can reasonably be used to transport a weblog between engines, but not broader. What you=E2=80=99re looking for is a full backup, but that=E2=80=99s a different use case than what (I think) this spec aims for. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Oct 17 09:01:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoZZ-0003Fd-UD for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:01:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZoZR-0005Gq-H2 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:01:33 -0400 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 k9HCgkW6093668; Tue, 17 Oct 2006 05:42: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 k9HCgkDU093667; Tue, 17 Oct 2006 05:42: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 netc-relay-2m.netcourrier.com (netc-relay-2m.netcourrier.com [194.158.104.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HCgiT5093661 for ; Tue, 17 Oct 2006 05:42:45 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-2m.netcourrier.com (Postfix) with SMTP id 9385AB0CD for ; Tue, 17 Oct 2006 14:42:43 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org Subject: [atom-syntax] [RFC 4685] uri in xml namespace Date: Tue, 17 Oct 2006 14:42:43 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: 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 k9HCgjT5093662 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 The RFC 4685 define an xml namespace with "http://purl.org/syndication/thread/1.0". An HTTP GET http://purl.org/syndication/thread/1.0 answer HTTP/1.x 302 Found Location: http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt which redirect to http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt which answer HTTP/1.x 404 Not Found Please fix this issue and make http://purl.org/syndication/thread/1.0 redirecting to http://www.ietf.org/rfc/rfc4685.txt or http://tools.ietf.org/html/rfc4685 or http://www.rfc-editor.org/*4685*. From owner-atom-syntax@mail.imc.org Tue Oct 17 09:09:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoh5-0007ZM-4a for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:09:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZoh3-0006RF-NR for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:09:19 -0400 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 k9HCku3p094105; Tue, 17 Oct 2006 05:46: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 k9HCkujD094104; Tue, 17 Oct 2006 05:46: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9HCkrFS094033 for ; Tue, 17 Oct 2006 05:46:54 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 Oct 2006 12:46:47 -0000 Received: from xdsl-213-196-225-211.netcologne.de (EHLO klangraum) [213.196.225.211] by mail.gmx.net (mp031) with SMTP; 17 Oct 2006 14:46:47 +0200 X-Authenticated: #163624 Date: Tue, 17 Oct 2006 14:46:46 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Atom Export Message-ID: <20061017124646.GE26771@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k9HCku3p094105 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 * Alastair Rankine [2006-10-17 14:05]: > So the list is now: >=20 > 1. Complete list of authors defined. For each author: > a. Name > b. URI > c. email > 2. Complete list of categories defined: > a. Name > b. URI > 3. All articles. For each article: > a. Source text > b. All the relevant metadata from the Atom spec, namely: > author, ID, published, rights, title, updated, summary,=20 > categories > c. Some other metadata: > draft status, syntax of source > 4. All comments and trackbacks. For each comment or trackback: > a. Source text > b. Atom spec metadata: > author, ID, title, published, summary, avatar? > c. Additional metadata: > pointer to parent article or comment (ie "in-reply-to") > 5. All "Owned" media. For each media object: > a. URI > b. MIME type > c. Binary data >=20 > Does this look about right? Obviously there would need to be > a liberal sprinkling of extension points for proprietary > information. I think it is a good idea to also include the translated text of each article, comment, etc. Eg. if they=E2=80=99re written in Markdown, they should be accompanied by an HTML version, so that when migrating to an engine which does not have Markdown support, such articles and comments are not lost. The trouble is with the content model. Suppose a weblog supports distinct summaries and main articles, and it supports Markdown. Firstly, text constructs do not support arbitrary MIME type; only atom:content does. Secondly, there are then two instances of the textual content of every supported field. If titles may contain inline Markdown markup, how do you preserve that? I=E2=80=99m not sure what to do about this. The first thing that comes to mind is that to accompany each atom:foo text construct with a corresponding src:foo element, but I don=E2=80=99t know whether this is a good idea. There are two options here: either the elements are placed directly inside the atom:entry as extension elements, or they are collectively placed inside the atom:content as instances of an independent XML vocabulary. The latter seems favourable, but again I don=E2=80=99t know whether any of this is really a good idea. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Oct 17 09:14:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZolr-0002tc-Rw for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:14:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZolk-0007EM-Af for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:14:15 -0400 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 k9HCvuRp095127; Tue, 17 Oct 2006 05: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 k9HCvukU095126; Tue, 17 Oct 2006 05: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HCvtBd095115 for ; Tue, 17 Oct 2006 05:57:55 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 95612 invoked by uid 17064); 17 Oct 2006 12:57:55 -0000 Received: from unknown (HELO [192.168.1.5]) ([62.47.188.40]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Oct 2006 12:57:55 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <59790F56-A86B-43F8-8BDE-F504E514AB4C@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: atom-protocol Protocol , Atom Syntax From: Henry Story Subject: SPARQLing Roller Date: Tue, 17 Oct 2006 14:58:15 +0200 X-Mailer: Apple Mail (2.752.2) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9HCvuBd095116 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 k9HCvuRp095127 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 I have recently been working on adding a SPARQL end point to a test =20 Roller weblogger server. Using the D2RQ library developed at the Freie Universit=E4t of Berlin =20 and the Roller Weblogger software that is powering blogs.sun.com, I =20 have put up a test server that maps Roller's mysql tables to the =20 AtomOwl ontology. I have blogged about this in more length with hyperlinks to =20 presentations, the online server, and all the components. http://blogs.sun.com/bblfish/entry/sparqling_roller This could work very nicely with the PaceSparqlLink I proposed some =20 months ago. http://www.intertwingly.net/wiki/pie/PaceSparqlLink Henry Foaf name: http://bblfish.net/people/henry/card#me From owner-atom-syntax@mail.imc.org Tue Oct 17 09:22:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZou2-00083D-0b for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:22:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZotx-00082d-FO for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:22:41 -0400 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 k9HD56Wp095663; Tue, 17 Oct 2006 06:05: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 k9HD563n095662; Tue, 17 Oct 2006 06:05: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 netc-relay-3m.netcourrier.com (netc-relay-3m.netcourrier.com [194.158.104.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HD54d1095653 for ; Tue, 17 Oct 2006 06:05:05 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-3m.netcourrier.com (Postfix) with SMTP id 15C52B17C; Tue, 17 Oct 2006 15:05:02 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org, www-international@w3.org Cc: public-i18n-geo@w3.org Subject: Re: [atom-syntax] Atom bidi Date: Tue, 17 Oct 2006 15:05:02 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: 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 k9HD55d1095656 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e To: atom-syntax@imc.org, www-international@w3.org Copy to: public-i18n-geo@w3.org James Snell wrote in http://www.imc.org/atom-syntax/mail-archive/msg18925.html > To: atom-syntax atom-syntax@imc.org > Subject: Atom bidi > From: James M Snell Date: Fri, 13 Oct 2006 13:20:28 -0700 > As an alternative to adding the dir attribute to rfc4287, I've published > draft-snell-atompub-bidi-00.txt as an extension in a separate namespace. > > As always, feedback is requested and welcome. > > - James > > -------- Original Message -------- > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Atom Bidirectional Extension > Author(s) : J. Snell > Filename : draft-snell-atompub-bidi-00.txt > Pages : 8 > Date : 2006-10-13 > > This document describes an extension to the Atom format that can be > used to define the base directionality of directionally-neutral > characters contained within an Atom document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-00.txt > The goal and the draft seem good to me. There are at least 4 specifications to define the directionality of text in xml format: specification: Atom Bidirectional Extension URI: urn:ietf:id:draft-snell-atompub-bidi urn:ietf:id:draft-snell-atompub-bidi-00 http://tools.ietf.org/id/draft-snell-atompub-bidi* attribute: dir values: ltr, rtl, lro, rlo xml namespace: http://purl.org/atompub/bidi status: working draft specification: XHTML 1.0 URI: http://www.w3.org/TR/xhtml1 http://www.w3.org/TR/2002/REC-xhtml1-20020801 attribute: dir values: ltr, rtl xml namespace: http://www.w3.org/1999/xhtml status: usable specification: XHTML 2.0 URI: http://www.w3.org/TR/xhtml2/mod-bidi.html#adef_bidi_dir http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-bidi.html#adef_bidi_dir attribute: dir values: ltr, rtl, lro, rlo xml namespace: http://www.w3.org/2002/06/xhtml2/ status: working draft specification: Internationalization Tag Set 1.0 URI: http://www.w3.org/TR/its/#dir-sec http://www.w3.org/TR/2006/WD-its-20060518/#dir-sec attribute: dir values: ltr, rtl, lro, rlo xml namespace: http://www.w3.org/2005/11/its status: working draft editor: W3C Internationalization Tag Set working group http://www.w3.org/International/its/ XHTML 1.0 is the only specification which is not a working draft, but its dir attribute does not allow "lro" and "rlo" values. I do not guess XHTML 2.0 will be usable before a long time. What are the roadmap for "Atom Bidirectional Extension" and "Internationalization Tag Set 1.0" ? On the today speed, when are they sheduled, when can we hope, that it will be internet^W xml standard and published as "W3C Recommendation" or "IETF RFC" ? Could it be avoided having two spec for the same purpose ? See also - Richard Ishida, "What you need to know about the bidi algorithm and inline markup", http://www.w3.org/International/articles/inline-bidi-markup/ - W3C Internationalization Tag Set working group, "Best Practices for XML Internationalization", section 2.2 "Provide a way to specify text directionality", http://www.w3.org/TR/xml-i18n-bp/#DevDir - James Snell, "Adding bidi support to Atom", http://www.snellspace.com/wp/?p=470 - James Snell, "Atom Bidirectional Extension", http://www.snellspace.com/wp/?p=484 - "PaceAtomBidi", http://www.intertwingly.net/wiki/pie/PaceAtomBidi - "FAQ: Bidi formatting codes vs. markup in (X)HTML", http://www.w3.org/International/questions/qa-bidi-controls - "FAQ: CSS vs. markup for bidi support", http://www.w3.org/International/questions/qa-bidi-css-markup From owner-atom-syntax@mail.imc.org Tue Oct 17 10:01:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUo-00009A-K2 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 10:00:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpHY-0001sO-Ks for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 09:47:04 -0400 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 k9HDVu2r098292; Tue, 17 Oct 2006 06:31: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 k9HDVup9098291; Tue, 17 Oct 2006 06:31: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 mail.internode.on.net (bld-mail07.adl2.internode.on.net [203.16.214.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HDVsZs098280 for ; Tue, 17 Oct 2006 06:31:55 -0700 (MST) (envelope-from arsptr@internode.on.net) Received: from [192.168.1.3] (unverified [59.167.4.175]) by mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 47250337 for multiple; Tue, 17 Oct 2006 23:01:45 +0930 (CST) In-Reply-To: <20061017124646.GE26771@klangraum> References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> <20061017124646.GE26771@klangraum> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <7A707C8F-A1B3-4DCE-9A3A-7D705C0A10CA@internode.on.net> Cc: atom-syntax@imc.org From: Alastair Rankine Subject: Re: Atom Export Date: Tue, 17 Oct 2006 23:31:42 +1000 To: "A. Pagaltzis" X-Mailer: Apple Mail (2.752.2) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9HDVuZs098286 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 k9HDVu2r098292 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On 17/10/2006, at 10:46 PM, A. Pagaltzis wrote: > I think it is a good idea to also include the translated text of > each article, comment, etc. Eg. if they=92re written in Markdown, > they should be accompanied by an HTML version, so that when > migrating to an engine which does not have Markdown support, such > articles and comments are not lost. Aside from the implementation issues I am unconvinced that this is a =20 good idea in the first place. If we have two alternative representations for an entry in the export =20 file, it forces the importer *code* to choose which representation is the best match for the target blogging engine. It =20 is not obvious to me that the code will always be able to make this =20 decision in the best manner. Also, it's not obvious whether or not =20 the redundant ("cooked") HTML representation will be "good enough". =20 This content negotiation has the potential to significantly =20 complicate the job of the importer. I thought it might be simpler for the *exporter* to choose a content =20 syntax - perhaps with the help of the user - which is deemed to be =20 the most interoperable, and yet closest to the original. For example, a Typo implementation would probably export in the =20 source Textile/Markdown/whatever, and yet expand all the macros =20 because these are by definition not interoperable. And yet if the =20 user is exporting from one Typo installation to another, they =20 probably don't want to expand these macros, so the decision probably =20 needs to be under user control. My assumption here is that the user prettymuch always knows what is =20 the right level of translation to be done on the data when moving =20 their data from one system to another. This may well be an incorrect =20 assumption. Even in the worst case, namely the user has authored their data in a =20 format that is just not supported at all on the target platform, =20 should it necessarily be the exporter that resolves this problem? It =20 could be an *intermediate* tool that converts the content from one =20 format to another, on behalf of the target platform. For example, a =20 tool that renders all Markdown-formatted content into HTML would be =20 very simple to write and would also achieve the required goal. So despite all the above I'm not totally *against* the idea of =20 supplying multiple representations in the export file, but I do think there are alternatives which should be considered. From owner-atom-syntax@mail.imc.org Tue Oct 17 10:23:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqP-0007wl-0X for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 10:23:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpij-0004fQ-9G for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 10:15:08 -0400 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 k9HDmcH0099977; Tue, 17 Oct 2006 06:48: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 k9HDmc0q099976; Tue, 17 Oct 2006 06:48: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9HDmapt099967 for ; Tue, 17 Oct 2006 06:48:37 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 Oct 2006 13:48:31 -0000 Received: from xdsl-213-196-225-211.netcologne.de (EHLO klangraum) [213.196.225.211] by mail.gmx.net (mp019) with SMTP; 17 Oct 2006 15:48:31 +0200 X-Authenticated: #163624 Date: Tue, 17 Oct 2006 15:48:30 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Atom Export Message-ID: <20061017134830.GF26771@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> <20061017124646.GE26771@klangraum> <7A707C8F-A1B3-4DCE-9A3A-7D705C0A10CA@internode.on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A707C8F-A1B3-4DCE-9A3A-7D705C0A10CA@internode.on.net> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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: d6b246023072368de71562c0ab503126 * Alastair Rankine [2006-10-17 15:35]: > I thought it might be simpler for the *exporter* to choose > a content syntax - perhaps with the help of the user - which > is deemed to be the most interoperable, and yet closest to the > original. That is a good counter. However, you still need to address the restriction of text constructs, namely that in Atom, they can be only of type `text` (with no semantics implied for whitespace), `html` or `xhtml`. Without further provisions you can only export the cooked content of elements other than atom:content. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Oct 17 11:36:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqzl-0001NP-Tm for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:36:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqzi-00056v-G7 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:36:45 -0400 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 k9HEwlAn009310; Tue, 17 Oct 2006 07:58: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 k9HEwlHB009309; Tue, 17 Oct 2006 07:58: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 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 k9HEwkhx009303 for ; Tue, 17 Oct 2006 07:58:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so307233wri for ; Tue, 17 Oct 2006 07:58:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=oNIAptsLIG2wlF1bUXaPFmnsYlJAyu1v3I8RNUoBu0668BM31gYVtDBZub45l5VRzlOql4VmmBrowybIgWzfS+6sTZnZIp9zVIMUbKXJQo9fJ5oTDKOw9Rt1nY8QjMMRVpUa2AERQa7Y7rMiua/qP8SCVrJJuutneJ3NwnAJiac= Received: by 10.90.52.2 with SMTP id z2mr4920668agz; Tue, 17 Oct 2006 07:58:45 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 7sm648868wrl.2006.10.17.07.58.44; Tue, 17 Oct 2006 07:58:45 -0700 (PDT) Message-ID: <4534EFA1.80906@gmail.com> Date: Tue, 17 Oct 2006 07:58:41 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Nicolas Krebs CC: atom-syntax@imc.org Subject: Re: [atom-syntax] [RFC 4685] uri in xml namespace References: In-Reply-To: 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Done! - James Nicolas Krebs wrote: > The RFC 4685 define an xml namespace with > "http://purl.org/syndication/thread/1.0". > An HTTP GET http://purl.org/syndication/thread/1.0 answer > HTTP/1.x 302 Found > Location: http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt > > which redirect to > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt > > which answer > HTTP/1.x 404 Not Found > > Please fix this issue and make http://purl.org/syndication/thread/1.0 > redirecting to http://www.ietf.org/rfc/rfc4685.txt or > http://tools.ietf.org/html/rfc4685 or http://www.rfc-editor.org/*4685*. > > > > > From owner-atom-syntax@mail.imc.org Tue Oct 17 11:37:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr0S-0001gh-AP for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:37:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZr0Q-00059E-V8 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:37:28 -0400 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 k9HFHA0C011259; Tue, 17 Oct 2006 08:17: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 k9HFHACn011257; Tue, 17 Oct 2006 08:17: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HFH7KK011250 for ; Tue, 17 Oct 2006 08:17:07 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so329735nfa for ; Tue, 17 Oct 2006 08:17:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=juPOkVy6i31TJhJ6wL9wIb4hznd0mwTBpXewisRiK0+S7v0rJchzOGEQzCiNCjkK65wQlz0WCmOtN7bV2muPNQbUX2SGcyh/Da0+YqJw9z3gDjlTjEsXChbsvtyRAp0N/VEZyDQJxHIbQJOaUaJ23gyCCLbMJxmrl9iDrdgA+Qo= Received: by 10.82.131.1 with SMTP id e1mr1477948bud; Tue, 17 Oct 2006 08:17:05 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm1296607wrl.2006.10.17.08.17.04; Tue, 17 Oct 2006 08:17:05 -0700 (PDT) Message-ID: <4534F3ED.4050004@gmail.com> Date: Tue, 17 Oct 2006 08:17:01 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Atom Export References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> <20061017122603.GD26771@klangraum> In-Reply-To: <20061017122603.GD26771@klangraum> Content-Type: text/plain; charset=UTF-8 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 k9HFHA0C011259 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 I agree, however, the format should be extensible enough to support broader use cases. With Atom extensibility, this is very easy to achieve without allowing the scope of the spec to creep too far. - James A. Pagaltzis wrote: > * James M Snell [2006-10-04 17:30]: >> I would add to this information about what plugins have been >> applied and what templates have been used. These, of course, >> are not going to be portable to different blog environments but >> the information would be necessary in order to faithfully >> recreate the entries later. >=20 > -1 >=20 > These should be engine-specific extensions. The format should be > broad enough in scope that it can reasonably be used to transport > a weblog between engines, but not broader. What you=E2=80=99re looking > for is a full backup, but that=E2=80=99s a different use case than what > (I think) this spec aims for. >=20 > Regards, From owner-atom-syntax@mail.imc.org Tue Oct 17 11:51:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrEC-0007Q7-A0 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:51:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrEA-00078L-TC for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:51:40 -0400 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 k9HFFIjA011054; Tue, 17 Oct 2006 08:15: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 k9HFFIM8011053; Tue, 17 Oct 2006 08:15: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HFFEAG011040 for ; Tue, 17 Oct 2006 08:15:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so1899329wxc for ; Tue, 17 Oct 2006 08:15:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EKDgDNbN7QzW4OGPDqvjJzlQseij0grbOODSuKHlliZwwbUCeTkblKJZbXA4srTr0pz/p2aKJaAqKkS7WNu2XwwjWnWeWd0ZvSixwYYlQcq6xSk9t6DjquqPYvNrRkfMoOMHunqdc/oNjJbstKxmmjOEmpHSMLxrncN8IfG0/Og= Received: by 10.90.55.19 with SMTP id d19mr4935813aga; Tue, 17 Oct 2006 08:15:14 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 43sm404838wri.2006.10.17.08.15.13; Tue, 17 Oct 2006 08:15:13 -0700 (PDT) Message-ID: <4534F37E.4000904@gmail.com> Date: Tue, 17 Oct 2006 08:15:10 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Nicolas Krebs CC: atom-syntax@imc.org, www-international@w3.org, public-i18n-geo@w3.org Subject: Re: [atom-syntax] Atom bidi References: In-Reply-To: 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: 8b30eb7682a596edff707698f4a80f7d The key challenge with using ITS in Atom is its complexity and scope. Atom simply doesn't need to do that much. - James Nicolas Krebs wrote: > [snip] > XHTML 1.0 is the only specification which is not a working draft, but its > dir attribute does not allow "lro" and "rlo" values. > > I do not guess XHTML 2.0 will be usable before a long time. > > What are the roadmap for "Atom Bidirectional Extension" and > "Internationalization Tag Set 1.0" ? On the today speed, when are they > sheduled, when can we hope, that it will be internet^W xml standard and > published as "W3C Recommendation" or "IETF RFC" ? > > Could it be avoided having two spec for the same purpose ? > > See also > - Richard Ishida, "What you need to know about the bidi algorithm and inline > markup", http://www.w3.org/International/articles/inline-bidi-markup/ > - W3C Internationalization Tag Set working group, "Best Practices for XML > Internationalization", section 2.2 "Provide a way to specify text directionality", > http://www.w3.org/TR/xml-i18n-bp/#DevDir > - James Snell, "Adding bidi support to Atom", http://www.snellspace.com/wp/?p=470 > - James Snell, "Atom Bidirectional Extension", http://www.snellspace.com/wp/?p=484 > - "PaceAtomBidi", http://www.intertwingly.net/wiki/pie/PaceAtomBidi > - "FAQ: Bidi formatting codes vs. markup in (X)HTML", > http://www.w3.org/International/questions/qa-bidi-controls > - "FAQ: CSS vs. markup for bidi support", > http://www.w3.org/International/questions/qa-bidi-css-markup > > > > > From owner-atom-syntax@mail.imc.org Tue Oct 17 11:57:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrK6-00010v-NB for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:57:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrK0-0007y0-AS for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 11:57:46 -0400 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 k9HFduoQ014007; Tue, 17 Oct 2006 08: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 k9HFdut0014006; Tue, 17 Oct 2006 08: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 mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HFdutY013996 for ; Tue, 17 Oct 2006 08:39:56 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 26484 invoked from network); 17 Oct 2006 15:39:50 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Oct 2006 15:39:50 -0000 Message-ID: <4534F944.6070602@metalab.unc.edu> Date: Tue, 17 Oct 2006 11:39:48 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Atom Export of source text References: <451ADD04.4070005@dehora.net> <451AE153.4080108@gmail.com> <4520AC9A.9090001@gmail.com> <45212065.3050203@metalab.unc.edu> <0C6BB17F-0048-4566-8E5B-F6B7AD7B4332@internode.on.net> <4522549C.7040207@metalab.unc.edu> <7AE386DC-7D4F-490D-A020-423CD1AE58C4@internode.on.net> <4523CE66.4070204@gmail.com> In-Reply-To: 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 k9HFduoQ014007 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Alastair Rankine wrote: > 4. All comments and trackbacks. For each comment or trackback: > a. Source text This one needs to be expanded somewhat. In particular is it: A. The text of the entry as published in an Atom feed? or B. The source of that text as it appears in the original? In WordPress, for example, these two can be quite different. The real=20 source is likely not HTML or XHTML, while the Atom output is. I recommend choosing A. I think it's the only one that has a chance of=20 being interoperable. --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai= tA/ From owner-atom-syntax@mail.imc.org Tue Oct 17 12:29:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZroK-0000fj-Bq for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 12:29:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZroF-0003ds-V5 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 12:29:00 -0400 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 k9HG9FYU016338; Tue, 17 Oct 2006 09:09: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 k9HG9FXv016337; Tue, 17 Oct 2006 09:09: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 wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HG9DnL016330 for ; Tue, 17 Oct 2006 09:09:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so323544wri for ; Tue, 17 Oct 2006 09:09:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Zgxk+ogY/s5P8NEnhpnj+YW2b0t38/GONG3cPA2jWnOddb0YEbxb6DPAHgPap53CRUIeU9ycv4TYkBBH94ciHKaOSBUyif+exCn5rG0FJ37lsTSAcnJhbuHZJUF/ReTxkiq9BbPxb2QRYIaSd5arMh0qSYcljKNnMdtABLVKqFw= Received: by 10.90.79.6 with SMTP id c6mr5024919agb; Tue, 17 Oct 2006 09:09:13 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 13sm1433331wrl.2006.10.17.09.09.11; Tue, 17 Oct 2006 09:09:12 -0700 (PDT) Message-ID: <45350024.6010805@gmail.com> Date: Tue, 17 Oct 2006 09:09:08 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Yves Savourel CC: "'Nicolas Krebs'" , atom-syntax@imc.org, www-international@w3.org, public-i18n-geo@w3.org Subject: Re: [atom-syntax] Atom bidi References: <001501c6f204$4b9d2a60$9b05a8c0@Breizh> In-Reply-To: <001501c6f204$4b9d2a60$9b05a8c0@Breizh> 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: 93238566e09e6e262849b4f805833007 Yves, thanks for the input, comments below. Yves Savourel wrote: > [snip] > Atom could use just the local its:dir attribute and be ITS conformant. > Ok. this is good to know. > > I noticed the values described in atompub-bidi-00 include "" and default to it, while XHTML 1.0, XHTML 2.0, and ITS do not have "" > and default to "ltr". Is there any specific reason to have "" and default to it? > Currently Atom has no directionality metadata at all. Implementations cannot make any assumptions about the base directionality of the text. Defaulting to "" preserves that case. This extension spec cannot reasonably say that the default directionality of text in an Atom feed that doesn't use the u:dir attribute is LTR when there is nothing in RFC4287 that backs up that claim. - James From owner-atom-syntax@mail.imc.org Tue Oct 17 12:29:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrpB-0000xH-6Y for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 12:29:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrp3-0003mz-E2 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 12:29:53 -0400 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 k9HGAMwt016464; Tue, 17 Oct 2006 09:10: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 k9HGAMHa016463; Tue, 17 Oct 2006 09:10: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 bay0-omc1-s40.bay0.hotmail.com (bay0-omc1-s40.bay0.hotmail.com [65.54.246.112]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HGAJgq016435 for ; Tue, 17 Oct 2006 09:10:21 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.149]) by bay0-omc1-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 09:09:37 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Oct 2006 09:09:36 -0700 Message-ID: Received: from 81.179.103.143 by BAY120-DAV11.phx.gbl with DAV; Tue, 17 Oct 2006 16:09:33 +0000 X-Originating-IP: [81.179.103.143] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: , , References: <4534F37E.4000904@gmail.com> Subject: Re: [atom-syntax] Atom bidi Date: Tue, 17 Oct 2006 17:07:44 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 17 Oct 2006 16:09:36.0835 (UTC) FILETIME=[A4638930:01C6F206] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de If you're going to require a separate namespace for bidi support, maybe it's best to use XHTML 1.0 and just toss out the lro and rlo values. I know I was originally pushing for those to be included, but now that I've seen how inconsistent the bdo support is in browsers I think they're probably going to be a waste of time. Nobody is going to get them right. Regards James From owner-atom-syntax@mail.imc.org Tue Oct 17 13:15:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWb-0005Ea-NQ for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:14:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsMF-00080W-D7 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:04:13 -0400 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 k9HGi3YM020087; Tue, 17 Oct 2006 09:44: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 k9HGi32m020086; Tue, 17 Oct 2006 09:44: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HGi2jo020062 for ; Tue, 17 Oct 2006 09:44:02 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.0.4] (user-10876hc.cable.mindspring.com [64.131.154.44]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id E571E6A861B; Tue, 17 Oct 2006 09:43:55 -0700 (PDT) Message-ID: <45350845.90100@mozilla.com> Date: Tue, 17 Oct 2006 12:43:49 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org, www-international@w3.org, public-i18n-geo@w3.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@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: 7d33c50f3756db14428398e2bdedd581 fwiw, I have no intention of reading the Snell bidi draft, or implementing what might be inside. As I've mentioned several times, I am already implementing a solution. I will document it and roll it onto the standards track as an update to RFC4287. -Rob James Holderness wrote: > > If you're going to require a separate namespace for bidi support, > maybe it's best to use XHTML 1.0 and just toss out the lro and rlo > values. I know I was originally pushing for those to be included, but > now that I've seen how inconsistent the bdo support is in browsers I > think they're probably going to be a waste of time. Nobody is going to > get them right. > > Regards > James > From owner-atom-syntax@mail.imc.org Tue Oct 17 13:16:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsY3-0005sV-JZ for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:16:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsXz-0001yu-6t for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:16:15 -0400 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 k9HGquij021046; Tue, 17 Oct 2006 09:52: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 k9HGquPh021045; Tue, 17 Oct 2006 09:52: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HGqtcG021036 for ; Tue, 17 Oct 2006 09:52:56 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so1929629wxc for ; Tue, 17 Oct 2006 09:52:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fP7mts9/iSxZQvfn7rblQLeuYK3FYa64qwpbN9kQ4z8f+Cbm112AJH3b1sL3uOIisH3CelUpv7lXyWKWnpS/ILO5g/vuvItKjEikNhGNxcDDByjQ+zhXAyQUQzDaFEerfONayqx76e5lgvE+Hu5wxZpehvVxsKqKrJUmtDqx+14= Received: by 10.90.120.6 with SMTP id s6mr5113230agc; Tue, 17 Oct 2006 09:52:49 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 13sm1519140wrl.2006.10.17.09.52.47; Tue, 17 Oct 2006 09:52:49 -0700 (PDT) Message-ID: <45350A5D.2060307@gmail.com> Date: Tue, 17 Oct 2006 09:52:45 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org, www-international@w3.org, public-i18n-geo@w3.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> In-Reply-To: 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: d6b246023072368de71562c0ab503126 That's certainly a strong option. - James James Holderness wrote: > > If you're going to require a separate namespace for bidi support, maybe > it's best to use XHTML 1.0 and just toss out the lro and rlo values. I > know I was originally pushing for those to be included, but now that > I've seen how inconsistent the bdo support is in browsers I think > they're probably going to be a waste of time. Nobody is going to get > them right. > > Regards > James > > From owner-atom-syntax@mail.imc.org Tue Oct 17 13:20:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsbn-0006kn-GW for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:20:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsbm-0002Wv-5r for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:20:07 -0400 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 k9HH45oU022061; Tue, 17 Oct 2006 10:04: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 k9HH458t022060; Tue, 17 Oct 2006 10:04:05 -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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HH44Li022042 for ; Tue, 17 Oct 2006 10:04:05 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.0.4] (user-10876hc.cable.mindspring.com [64.131.154.44]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 1E2D76A862F; Tue, 17 Oct 2006 10:03:59 -0700 (PDT) Message-ID: <45350CF8.9030909@mozilla.com> Date: Tue, 17 Oct 2006 13:03:52 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James M Snell CC: atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45350845.90100@mozilla.com> <45350CC6.6010608@gmail.com> In-Reply-To: <45350CC6.6010608@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: 7aefe408d50e9c7c47615841cb314bed James M Snell wrote: > How kind of you. Would you mind sharing some of the details with us now > so that we can come to a common solution that works with more than just > Firefox and Thunderbird? It'll work fine with everythign From owner-atom-syntax@mail.imc.org Tue Oct 17 13:21:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsdU-0007Da-Mf for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:21:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsdT-0002nD-Al for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:21:52 -0400 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 k9HH38hb021946; Tue, 17 Oct 2006 10:03: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 k9HH380M021945; Tue, 17 Oct 2006 10:03: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HH360C021937 for ; Tue, 17 Oct 2006 10:03:07 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so1932756wxc for ; Tue, 17 Oct 2006 10:03:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Vm6PLjYsyhrloQHy9S32X3tGiRmF1KJDP2ZLWWdBsBIMed+hYlmqGkss8NQtYqexlJtoeWJpExNLl/zP8r+TQRrDlSKOufC51gd5me53FEz1dJiz7LtaQc4BzYkoC4KsFx2BJytUHoIH1fh9X3rSr392Y6tzzKUa7A12XAhrTT8= Received: by 10.90.54.4 with SMTP id c4mr5142526aga; Tue, 17 Oct 2006 10:03:06 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 8sm1730308wra.2006.10.17.10.03.04; Tue, 17 Oct 2006 10:03:05 -0700 (PDT) Message-ID: <45350CC6.6010608@gmail.com> Date: Tue, 17 Oct 2006 10:03:02 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45350845.90100@mozilla.com> In-Reply-To: <45350845.90100@mozilla.com> 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: 1ac7cc0a4cd376402b85bc1961a86ac2 How kind of you. Would you mind sharing some of the details with us now so that we can come to a common solution that works with more than just Firefox and Thunderbird? I really can't imagine that it would all that different than what I've documented and it would be silly to come up with an alternative solution simply because you don't like the author. - James Robert Sayre wrote: > > I will document it and roll it onto the standards track as an update to RFC4287. > [snip] From owner-atom-syntax@mail.imc.org Tue Oct 17 13:46:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZt17-0002xO-SI for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:46:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZt13-000646-63 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:46:17 -0400 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 k9HHEwXG022905; Tue, 17 Oct 2006 10:14: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 k9HHEw3j022904; Tue, 17 Oct 2006 10:14: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 ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HHEuG0022896 for ; Tue, 17 Oct 2006 10:14:56 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id 36so1104177uga for ; Tue, 17 Oct 2006 10:14:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type; b=WwpXYXnRliK6nOCgCMLkDyTr8cI5fi9H/85WHDOYsdE5F1LCWiU2uMGveNd9ZokiUfXqBkSy8eT1U0vhhpq1cZdPa5pESUQpm6LEK14oc3Fif1Vnxh365OrAvrrSNheHZA8HnGnGBhuCmgvXnQQSzcMAryIrBov8uv+0k5A91Ns= Received: by 10.66.222.9 with SMTP id u9mr10189609ugg; Tue, 17 Oct 2006 10:14:54 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 3sm1985368wrh.2006.10.17.10.14.53; Tue, 17 Oct 2006 10:14:54 -0700 (PDT) Message-ID: <45350F8A.2050506@gmail.com> Date: Tue, 17 Oct 2006 10:14:50 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45350845.90100@mozilla.com> <45350CC6.6010608@gmail.com> <45350CF8.9030909@mozilla.com> In-Reply-To: <45350CF8.9030909@mozilla.com> Content-Type: multipart/mixed; boundary="------------080108060507000603050408" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa This is a multi-part message in MIME format. --------------080108060507000603050408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robert Sayre wrote: > [snip] > It'll work fine with everythign > Would you mind sharing some details? Is there code already in the mozilla CVS I can go look at? I have some code already written that I'd like to get checked into Abdera soon. I'd prefer that it match what other implementors are doing or are planning to do. I personally don't mind who writes up the spec or whether it's done as an update to 4287 or not. Nor do I really care whose name ends up on the draft. Heck, we could probably even collaborate on the draft. Take what I've started with, make whatever changes you feel are necessary and add your name to the author list. I've attached the XML. - James --------------080108060507000603050408 Content-Type: text/xml; name="draft-snell-atompub-bidi-00.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-snell-atompub-bidi-00.xml" ]> Atom Bidirectional Extension
jasnell@gmail.com http://www.snellspace.com
General I-D Internet-Draft IRI URI Template This document describes an extension to the Atom format that can be used to define the base directionality of directionally-neutral characters contained within an Atom document.
This document describes an extension to the Atom format that can be used to define the base directionality of directionally-neutral characters contained within an Atom document.
The XML Namespaces URI for the XML elements and attributes described in this specification is
In this document, the namespace prefix "u:" is used for the above Namespace URI. Note that the choice of namespace prefix is arbitrary and not semantically significant.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, . This extension is, like the Atom Syndication Format itself, specified using terms from the XML Infoset . However, this specification uses a shorthand form for two commons terms: The phrase "Information Item" is omitted when naming Element and Attribute Information Items. Therefore, when this specification uses the term "element," it is referring to an Element Information Item in Infoset terms. Likewise, when it uses the term "attribute," it is referring to an Attribute Information Item. Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema . However, the text of this specification provides the sole definition of conformance.
The "u:dir" attribute specifies the base direction of directionally-neutral text . Possible values for the attribute are "ltr" and "rtl" indicating "left-to-right" and "right-to-left" respectively, "lro" and "rlo" indicating explicit "left-to-right" and "right-to-left" overrides, or an empty string indicating that no base-direction is specified. If the "u:dir" attribute is not specified, the value is assumed to be an empty string. The attribute can appear anywhere in an Atom document, except where it is explicitly forbidden.
The direction specified by "u:dir" applies only to elements and attributes whose values are specified as being "Language-Sensitive" as defined by Section 2 of . The attribute is inherited by descendent elements and may be overridden. Example atom:feed with right-to-left directionality
ٹٺٻ ... ]]>
If an Atom document contains any right-to-left characters, the Unicode Bidirectional Algorithm MUST be used to render that text. Because consumers of Atom documents vary broadly in the way they display text, the "ltr" and "rtl" values do not necessarily open an additional level of embedding with respect to the bidirectional algorithm. Consuming applications that render bidirectional text are responsible for determining the appropriate level of embedding. The "lro" and "rlo" values override the inherent directionality of characters as defined by . When used, affected text MUST be rendered as if preceded by either Unicode character U+202D (left-to-right override) or U+202E (right-to-left override) and followed by U+202C (pop directional formatting). When Atom Text Constructs or the atom:content elements contain bidirectional text and the type attribute is set to either "html" or "xhtml", the bidirectional markup mechanisms specific to each format SHOULD be used. The value of the "u:dir" attribute does define the base directionality of Language-Sensitive text within Text Constructs and atom:content elements regardless of the value of the type attribute. Example atom:feed with bidirectional XHTML:
<div xmlns="http://www.w3.org/1999/xhtml"> <p dir="rtl">ٹٺٻ</p> </div> ... ]]>
The Unicode bidirectional control characters MAY also be used within attributes and element values to indicate the directionality of text. Implementers are reminded that unexpected results could occur when using both the "u:dir" attribute and the Unicode control characters within a single document.
The security considerations discussed in Section 8 apply.
No IANA actions are required by this document.
&rfc2119; &rfc4287; &xmlnames; &infoset; ISO/IEC 10646:2003: Information Technology - Universal Multiple-Octet Coded Character Set (UCS) International Organization for Standardization The Bidirectional Algorithm International Organization for Standardization RELAX NG Compact Syntax
TBD
--------------080108060507000603050408-- From owner-atom-syntax@mail.imc.org Tue Oct 17 13:46:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZt1J-00037s-Ox for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:46:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZt1I-00065S-E5 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 13:46:29 -0400 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 k9HHBHbe022596; Tue, 17 Oct 2006 10:11: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 k9HHBHRC022595; Tue, 17 Oct 2006 10:11: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HHBGpM022581 for ; Tue, 17 Oct 2006 10:11:16 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.0.4] (user-10876hc.cable.mindspring.com [64.131.154.44]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id B925A6A87FE; Tue, 17 Oct 2006 10:11:10 -0700 (PDT) Message-ID: <45350EA8.5040200@mozilla.com> Date: Tue, 17 Oct 2006 13:11:04 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: James M Snell CC: atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45350845.90100@mozilla.com> <45350CC6.6010608@gmail.com> In-Reply-To: <45350CC6.6010608@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad James M Snell wrote: > Would you mind sharing some of the details with us now > so that we can come to a common solution that works with more than just > Firefox and Thunderbird? That is absurd. This message has used up my atom-syntax time for the moment, so I guess you'll have to wait, or use up other people's atom-syntax time. -Rob From owner-atom-syntax@mail.imc.org Tue Oct 17 14:35:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZtmH-0001eD-MW for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 14:35:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZtmE-000348-AU for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 14:35:01 -0400 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 k9HIA9XC027727; Tue, 17 Oct 2006 11:10: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 k9HIA8fn027726; Tue, 17 Oct 2006 11:10: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 dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HIA6hI027713 for ; Tue, 17 Oct 2006 11:10:08 -0700 (MST) (envelope-from rsayre@mozilla.com) Received: from [192.168.0.4] (user-10876hc.cable.mindspring.com [64.131.154.44]) (Authenticated sender: rsayre@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 6A7906A8113; Tue, 17 Oct 2006 11:09:59 -0700 (PDT) Message-ID: <45351C70.8070200@mozilla.com> Date: Tue, 17 Oct 2006 14:09:52 -0400 From: Robert Sayre User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Robert Sayre CC: James Holderness , atom-syntax@imc.org, www-international@w3.org, public-i18n-geo@w3.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45350845.90100@mozilla.com> In-Reply-To: <45350845.90100@mozilla.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: 856eb5f76e7a34990d1d457d8e8e5b7f Robert Sayre wrote: > > fwiw, I have no intention of reading the Snell bidi draft, or > implementing what might be inside. As I've mentioned several times, I > am already implementing a solution. I will document it and roll it > onto the standards track as an update to RFC4287. To be clear, I have no intention of ignoring input from this list, since that almost always results in improvements. I also have no intention of implementing anything that should have approval from the group, unless I have that approval. However, I don't think I'm obligated to let our more enthusiastic participants dictate the manner and pace of my personal contributions. -Rob From owner-atom-syntax@mail.imc.org Tue Oct 17 16:06:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCG-000253-Fr for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 16:05:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuyX-0004nS-8X for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 15:51:47 -0400 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 k9HJWsfg034246; Tue, 17 Oct 2006 12:32: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 k9HJWsvx034245; Tue, 17 Oct 2006 12:32: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.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HJWoKK034239 for ; Tue, 17 Oct 2006 12:32:53 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 58so9109wri for ; Tue, 17 Oct 2006 12:32:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rvMydVslz1AG3qCHdDwJust1Hq37Y5zipMQA7F274dis7xP8qYjjISkh7Dauv6b0CLaMXbBK/yzEdXr+Qn406JwoVStmSeGYWnKBsCXciThiYq9QVOty0H3oHUnkgSQwFhbxU4zeOUnPbqAhVO6/D6x65vvfbbDFLM6TSATeK6E= Received: by 10.90.105.19 with SMTP id d19mr5380377agc; Tue, 17 Oct 2006 12:32:50 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm106866wrl.2006.10.17.12.32.49; Tue, 17 Oct 2006 12:32:49 -0700 (PDT) Message-ID: <45352FDE.7020709@gmail.com> Date: Tue, 17 Oct 2006 12:32:46 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> In-Reply-To: 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 I've modified my very preliminary impl to support the use of xhtml:dir and have checked in some code [1]. The impl is very rough and designed only to illustrate the basic behavior I have in mind. Right now, the code determines the direction of text using the following steps (in order): 1. Look for an unprefixed "dir" attribute 2. Look for the xhtml:dir attribute 3. Look for any attribute with local-name="dir" and whose value looks appropriate (e.g. f:dir="ltr" xmlns:f="urn:foo" ) 4. If not found, iterate up through parent elements - James [1] http://tinyurl.com/ydb8uy James Holderness wrote: > > If you're going to require a separate namespace for bidi support, maybe > it's best to use XHTML 1.0 and just toss out the lro and rlo values. I > know I was originally pushing for those to be included, but now that > I've seen how inconsistent the bdo support is in browsers I think > they're probably going to be a waste of time. Nobody is going to get > them right. > > Regards > James > > From owner-atom-syntax@mail.imc.org Tue Oct 17 17:34:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwZx-0006tu-B5 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 17:34:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwZv-0006Uy-W5 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 17:34:29 -0400 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 k9HL5m9v042759; Tue, 17 Oct 2006 14:05: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 k9HL5m6a042758; Tue, 17 Oct 2006 14:05: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 netc-relay-3m.netcourrier.com (netc-relay-3m.netcourrier.com [194.158.104.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HL5k3i042750 for ; Tue, 17 Oct 2006 14:05:47 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-3m.netcourrier.com (Postfix) with SMTP id E6A4AB27E for ; Tue, 17 Oct 2006 23:05:45 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org Subject: Re: [atom-syntax] [RFC 4685] uri in xml namespace Date: Tue, 17 Oct 2006 23:05:45 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: 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 k9HL5m3i042753 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 James M Snell wrote >Done! Thanks. From owner-atom-syntax@mail.imc.org Tue Oct 17 18:39:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZxbC-0001ZO-Sr for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 18:39:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZxb5-0000pr-Rn for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 18:39:50 -0400 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 k9HM8Bf9047373; Tue, 17 Oct 2006 15:08: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 k9HM8Bq8047371; Tue, 17 Oct 2006 15:08: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 gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HM89Pc047353; Tue, 17 Oct 2006 15:08:10 -0700 (MST) (envelope-from ldusseault@commerce.net) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 982911F87; Tue, 17 Oct 2006 22:08:03 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.32M); Tue, 17 Oct 2006 22:08:03 GMT X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID312kJqwiD9723Xo1 Received: from [10.1.1.206] ([157.22.41.10]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:07:45 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) To: Atom , atom-protocol Protocol Message-Id: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> Content-Type: multipart/alternative; boundary=Apple-Mail-12-279554216 From: Lisa Dusseault Subject: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Tue, 17 Oct 2006 15:07:44 -0700 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 22:07:46.0984 (UTC) FILETIME=[AD840A80:01C6F238] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.2 (+) X-Scan-Signature: e2d51cd8a09fe8c6a7232f1d7a529f54 --Apple-Mail-12-279554216 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Despite the length of these comments, I feel this specification is =20 nearly there and I look forward to seeing its completion. There are =20 enough questions on this version, however, that it's worthwhile =20 pointing them out so that the WG can discuss before the document goes =20= out for wider review (IETF last call), to other people who haven't =20 been immersed in the discussions thus far and thus don't share the =20 same unstated assumptions. If the unstated assumptions are turned =20 into definitions or requirements in the document we'll get much =20 better IETF and then IESG review. Similarly, if undefined behaviors =20 are explicitly flagged as "undefined", then everybody is warned about =20= nasal demons -- a =20 spec that doesn't flag undefined behavior often leads to the reader =20 of the spec filling in unconsciously with their own assumptions (I =20 see that over and over and over again now that I'm reviewing so many =20 documents and discussing reviews with others). It would probably not be useful at this point for me to suggest a =20 resolution to absolutely everything, especially if that involves =20 specific wording. It's much more likely the WG/editors would choose =20 different wording and organization anyway. But when I get back from =20 vacation (1st day of November) and catch up on the mailing list =20 traffic, I will see if there's any place where I can suggest wording =20 to capture what I meant in a way that the WG can agree. I understand =20= there's often a balance between leaving options open for different =20 implementations and extensions, and closing options down so that =20 specific behavior can be depended on, and sometimes there are ways =20 you can have a little of both. High-level comments, summarizing comments - The mechanism for creating a media resource and a media link =20 entry in response to a single POST conflicts with at least one =20 statement elsewhere in the draft, and has no example. This is one of =20= those cases where I personally had some assumptions (that not every =20 media resource had its own media link entry if the media resource had =20= been created manually) that weren't ever quite cleared up by the =20 spec. If the client CAN create a media resource without also creating =20= a media link entry, that should be a separate example. - Overall, the responsibility model needs to be slightly better =20 defined. E.g. we know the server is responsible for choosing a URL =20 for new entries; it's not clear who's responsible for cleaning up =20 linked entries if a user ever needs to clean up historical entries. =20 Atom sometimes seems to split the responsibility, and those are the =20 most complicated cases. More examples below as it's probably more =20 useful to discuss specifics. - To an outsider or newcomer -- including me even though I've been =20 following discussions closely for a while -- there's a part of the =20 Atom model that's subtle but important to understand. Consumers of =20 Atom feeds are supposed to look at the regular feed document, whereas =20= publishers of Atom feeds are supposed to look at other, different =20 resources to see how to edit or create posts. Publishers effectively =20= look at a different feed than users do, one with extra metadata (the =20 rel=3D"edit" links). It's a different model than that of WebDAV or =20 IMAP, because rather than have the client specify which metadata it's =20= interested in, the server offers two choices with different =20 addresses. I believe it would be useful to cover that part of the =20 model upfront in addition to the other useful stuff already there. Creating resources Explicit result of POST, section 4. Are there zero, one or more resources created with a POST? There's a =20 line at the top of section 4 which says that "POST is used to create =20 a new, dynamically-named, resource". However, that implies ONE, =20 whereas with media entries, a POST could create TWO resources. I =20 believe a successful POST request as described here MUST either =20 result in one or two resources, never zero, and never 3 or more (in =20 the absence of extensions). What is the expected behavior of seeing a POST to an entry URL =20 (rather than a collection URL)? I see that this is currently =20 undefined; it may be worth stating that to warn clients. (I'm pretty =20= indifferent on this one, as in this case I can't see any obvious harm =20= in different server behaviors existing, if un-warned clients try it =20 intentionally without knowing the results. The only possible harm is =20= if clients got confused, did a POST to an entry URL when a collection =20= URL was intended, and the server does a success response which =20 creates new resources or modifies existing resources in a way the =20 client did not expect. An error response would certainly be harmless =20= for this undefined case but a success response could be real =20 interesting.) Creating entries with multiple media resources It's never explained how a client would go about creating a feed =20 entry with a number of media resources. I imagine that it could be =20 iterative; a client could create any of the resources at any time, =20 and at any time after creating the feed entry, use PUT to update the =20 feed entry to link to new media resources. I assume -- though I =20 didn't see it stated in the document -- that it's the client's =20 responsibility in almost all cases to put links in the feed entry to =20 point to the media resources, otherwise the media resources are =20 unlinked (effectively hidden to readers). The exception to this general process is if the client first uses =20 POST to create both the media resource and the "Media Link Entry" in =20 one go. In this case, can the "Media Link Entry" (MLE) be =20 transformed to a regular "Member Entry Resource" (MER)? I thought it =20= would be possible, but discussed just a bit with Tim today and he =20 says no, so there you have two different readings of the spec. I =20 guess a related question is what would happen if a client does a PUT =20 of media content to an entry resource, or entry content to a media =20 resource. It's not clear to me whether a linked media entry is always listed in =20= the metadata or not. - When one or more "edit-media" link relations appear, who has =20= been responsible for putting them there? - When a media resource is deleted, who is responsible for = removing =20 the media resource link from the MLE? - Section 4 says that the MLE contains the metadata for a Media =20= Resource, but that seems to only assume a single Media Resource. In =20 the case of multiple Media Resources which the user intends to link =20 into a single post, it's unclear to me whether there's one MLE for =20 every Media Resource, or one MER for all the Media Resources created, =20= or some other situation. Again, in quick discussion with Tim, he =20 says there is one Media Link Entry per Media Resource. I can see how =20= that would work but that was not at all my understanding before the =20 discussion! This document would benefit greatly from further examples: 1. An example of creating a MLE and MR in a single POST; the =20= request, response and the result (resource URLs) described. 2. An example of modifying a MER to contain a new image or = other =20 media resource link: the request(s), possibly the responses (if it's =20 interesting, it may not be), and definitely the result. 3. An example of modifying a MER to change metadata (e.g. = category =20 or adding a new link relation element or both); possibly a failed =20 request example would be even more interesting than a successful one. Can a client modify an entry to contain a link relation element in =20 the following cases: - To result in an "edit" or "edit-media" link relation, where = the =20 resource represented does not meet the requirements in section 11.1 =20 or 11.2? - To result in an "edit" link relation that actually points to a = =20 media resource, or a "edit-media" link relation that actually points =20 to a MER? - To point to a resource on a different server entirely? - To point to a valid media resource or MER that happen to be in = a =20 different collection than the one normally used for this feed? - Will some servers forbid adding a link relation element = entirely? =20 Is it important for the client to know that that will always be =20 forbidden for that server -- can it detect the "always forbidden" =20 case separately from the "this particular edit is forbidden" case? Which of these are errors, and if so how is the error handled? Which =20= of these MUST the server allow and handle? I understand there may be =20= some need for flexibility here. Perhaps it's just standardized error =20= messages required here. For example, if there are some servers which =20= allow a given link relation to point to another server, and some =20 servers which do not allow, how would the servers which do not allow =20 respond with a sufficiently specific error, so that the client can =20 avoid trying the same thing again? =09 Multiple formats/langs for media resources Multiple formats are not sufficiently defined -- e.g. JPG and PNG =20 versions of an image resource. Format negotiation is hard. I found =20 guidance for how to select among different "edit-media" link =20 relations depending on format and language, but I found no guidance =20 on how to create multiple versions. If there's no guidance to =20 clients or servers how to do it (would the client create multiple =20 resources in different formats? could the server automatically do it =20 as variants? could the server automatically do it as multiple =20 resources, and would all formats be therefore listed?), it's probably =20= worth considering whether there's possible interoperability harm =20 here. I can imagine clients creating alternate-format versions quite =20= successfully because the operations would be explicit, but when I =20 imagine how servers would go about it, I can easily see ways it could =20= go wrong (e.g. creating new URLs for resources that are invisible to =20 the media collection, having multiple URLs in locations where clients =20= expect only one). I think there may be a very basic confusion here -- in my head or in =20 the document or both -- about what the "edit-media" link relation =20 does and is for. When I read the text it seems to offer the =20 possibility for multiple formats for a single media resource, as =20 suggested by the text: "If a client encounters multiple "edit-media" =20 link relations in an entry then it SHOULD choose a link based on the =20 client preferences for type and hreflang". However, when I try to =20 think about how a client would create a post with a totally =20 independent set of JPG images (e.g. one of the Eiffel Tower, one of =20 the Louvre and one of the Arche de Triomphe), the "edit-media" link =20 relation also seems to have relevance. Which is it or both? (and as =20 always, who is responsible for filling it in or removing it when new =20 media resources are created or destroyed?) Thomas Broyer said in email July 24 that "Having the Content-=20 Location value equal to the Location one tells the client that the =20 response body is a representation of the newly created resource". =20 This is a subtle reading of HTTP and, if it's true, I want to make =20 sure that implementors understand this without having to read the =20 mailing list. The spec reads " the response from the server SHOULD =20 contain a Content-Location header that contains the same character-by-=20= character value as the Location header." If the response from the =20 server does not contain both headers identical, what should the =20 client conclude? I think this is one of those SHOULD recommendations =20= where the consequence of it not being a MUST need to be considered. =20 Possibly the spec needs to say under what conditions the server would =20= do otherwise; possibly the spec should say what the client knows, or =20 does not know, or must do, if the server does otherwise. Deleting Resources In the case of an entry that points to multiple media resources, can =20 the server delete all those media resources and their MLEs? (I think =20= not). If a client issues a DELETE to a media resource, is its MLE =20 deleted? (The spec covers the opposite case already when a client =20 issues a DELETE to an MLE.) Can collections be DELETEd? It's fine for servers to allow or no, =20 but if servers don't support, what error to use. Editing resources Overall, the process for editing a resource is not entirely clear. I =20= find the description of creating a resource (POST), and what the =20 server can accept, ignore or reject, more clear than the description =20 of editing a resource (PUT) . For example, there's normative text in =20= section 9.2.1 (an example) relative to creating resources and =20 handling metadata, but that text isn't duplicated for editing =20 resources or obviously apply to editing resources. Thus: - Can the client change the category? (probably yes; MUST the =20= server allow?) - Can the client change the atom:id? (probably never) - Can the client change the "updated" value to be some time in = the =20 future? Some time long ago? Or are there only two non-error changes =20 -- "now" or "the previous value"? MUST the server accept the value =20 if it's the same as the previous value? Or can there be servers that =20= always ignore "updated" values from clients? (and if so, is it =20 important for the client to know that the server does this) - Can the client change the set of link relations? (probably = yes; =20 but does that include "edit" and "edit-media" link relations only or =20 also first/previous/next/last link relations?) In general the possible edits need to be covered to consider whether =20 the server MUST allow these kinds of edits, or MAY, and if refused, =20 what error for what reason. I already threw in a request for an example of modifying a resource =20 above, because one of the cases for editing a resource is to add a =20 media resource to it. The spec says "The value of atom:updated is only changed when the =20 change to a member resource is considered significant. " The use of =20 passive voice obscures who does what here. When the client doesn't =20 suggest a value for "atom:updated", does the server provide one, and =20 if so, how does the server know what is "significant"? I thought it =20= would always be the client suggesting values, but Tim says that the =20 server controls atom:updated which could imply that the client =20 doesn't even need to suggest values. See above about whether the =20 server MUST accept certain values for "updated", or more likely, MUST =20= NOT accept suggested values for "updated" when they're clearly wrong =20 (e.g. this entry was last updated on October 16, 1906). Can a server ever ignore part of an edit and successfully process the =20= rest? For example, the server receives a PUT request that tries to =20 edit the text of a MER and includes a new category value, the server =20 accepts the new text but silently ignores the category value. I =20 suggest the answer would be MUST NOT silently ignore suggested =20 changes, particularly since there's no way in a PUT response to say =20 "here's what the server actually stored". It may be my opinion =20 differs here from that of the WG. I find silently ignoring input to =20 be scary. Synchronization I predict that some AtomPub authoring clients will attempt to =20 synchronize: to maintain an offline copy of the feed including all =20 its MERs and media resources, and to keep that offline copy up-to-=20 date. Some will probably even allow offline authoring of new posts, =20 and offer to synchronize when the client next goes online -- because =20 of the possibility of multiple authors, this may mean at times that =20 the client would download new entries created by other authors, =20 upload new entries created offline, and reconcile its offline copy of =20= feed documents. Because authoring clients will attempt to do this based on Last-=20 Modified and ETag -- after all, the functionality is all there in =20 some form or another -- the spec needs a little more clarity on how =20 the client can rely on this working. Otherwise, some servers may =20 omit features that these authoring clients require, or implement them =20= oddly. While I would never suggest repeating all the requirements =20 from other specs (in this case HTTP), there are cases where clarity =20 and interoperability are greatly improved by at least referencing =20 explicitly requirements from HTTP. It's also possible to add new =20 requirements based on features in HTTP, that apply to Atom servers =20 alone. You can see that I lean more towards the "explain confusing things" =20 side and "add more stringent requirements" than to the "it's already =20 written elsewhere side" by peeking at section 8.2 of CalDAV . A =20 mostly-explanatory guidelines section helps clients quickly =20 understand a clear path towards synchronization, and new requirements =20= for supporting ETags make things easier for what is, after all, a =20 more limited use case of HTTP (calendaring) than the general case. =20 If HTTP synchronization in authoring cases were clearly defined and =20 had not lead to years of arguments since the last HTTP update, I =20 would probably feel differently about just silently relying on the =20 mechanisms in HTTP. In any case, I have very specific brief suggestions to cover =20 synchronization so that it's implemented more successfully than not. - Consider adding a brief section offering clients non-normative = =20 guidelines on synchronization. It doesn't have to limit server =20 behavior so much as point out with green and red lights where the =20 fairway is (mixing transportation and golfing metaphors in my head) - Make a few requirements of servers to avoid some of those HTTP = =20 ambiguities. For example: "The ETag or Last-Modified values for a member resource MUST = change =20 when any metadata in the resource changes, as well as text/content, =20 and this includes "next" and "last" link relation values. The ETag =20 or Last-Modified values of a member resource MUST NOT change solely =20 because an associated other resource (e.g. the media resource being =20 an associated resource to the media link entry resource) changed. " More open questions that might be related to synch or might have =20 relevance even for clients that don't do full synch: - What is the relationship, if any, between the "atom:updated" = value =20 and the HTTP "Last-Modified" value. Can the "atom:updated" value =20 ever be later (greater) than the "Last-Modified" value? I believe it =20= can be the same or earlier, but the spec doesn't disallow the broken =20 case. - Is it clear whether the client MUST GET the entry after = modifying =20 it in order to have an accurate offline cache? (this was mentioned =20 in a post by Broyer Jul 13, but not in the document). I believe this =20= is made clear already for the cases of getting the feed and also for =20 POST/create, but not for PUT/modify. - Am I correct that the general assumption is that id's are = there to =20 see what entries are new, and URLs are there to see where to get =20 them? That may mean that URLs could change, for a given ID -- =20 Perhaps a feature to change the slug name of a image after attaching =20 it. Is that theoretically possible? There are also efficiency considerations. - The spec could require that servers MUST return either the = ETag, =20 or the Last-Modified value, in any successful POST or PUT response. =20 I personally favour this so that clients can rely on it, though =20 obviously other opinions are valid here. - I really liked the idea of putting ETag in the author's feed, = as =20 discussed on the list but not appearing in the document, again for =20 efficiency. Certainly, the spec could ignore these considerations for now. =20 However, I have noted that many client implementations choose a =20 single way to implement their logic that can be relied upon if a =20 reliable approach is available, rather than respond differently to =20 different implementations. Thus, I predict that if some servers =20 implement more-efficient synchronization and others don't, clients =20 will behave as if they're always talking to the less-efficient =20 servers. The more-efficient servers will find it difficult to achieve =20= better scalability through synch efficiency improvements because =20 clients have already implemented reliable but inefficient =20 synchronization and don't have reason to add a second logic path for =20 the more-efficient servers. Internationalization How are categories compared? Case-sensitive, insensitive, according =20 to which language? Would the categories "donn=E9" and "donne" map to =20 the same category as "Donne" and "DONNE"? I believe it's currently up =20= to the server, which means unpredictable behavior from the point of =20 view of clients. See http://www.ietf.org/internet-drafts/draft-newman-=20= i18n-comparator-14.txt, which has passed IESG Evaluation except for =20 some IANA actions. This is a danger area for any draft going before =20= the IESG which looks carefully at i18n these days. How do lang tags inside the document relate to Content-Language =20 information in headers? Does the most granular override the other =20 possible values? What about when client provides to server? Does the =20= server ignore or handle? Other The requirements for the link relations "next", "previous", "first" =20 and "last" aren't as rigorous as for "edit" and "edit-media" link =20 relations. Also they're defined quite separately -- I kind of =20 thought that all the link relation types could be usefully defined in =20= one section but if the editors prefer a different organization that's =20= fine. But; is it OK if the resource pointed to by one of these link =20 relations is on another server, in another feed, is a different kind =20 of resource than you might normally expect, etc... ? I think the =20 normal cases for these link relations are well-understood but not =20 necessarily what a client should do if it encounters abnormal cases. Discovering feed reading URL A very minor feature request for the introspection document: it =20 SHOULD contain the public or published read-only feed URL of the blog =20= (Tim suggests using link rel=3D"alternate" type=3D"application/atom+xml", = =20 although I'm not sure that makes it sufficiently clear what it's =20 for). This so that my blog editing tool can show me not only all =20 the entries and media resources (all discoverable from the =20 introspection doc already) but also where the blog is published, so =20 that I can copy that link to my friends when telling them about my blog. Extensions When the client puts extension elements in a MER, MUST the server =20 store those unrecognized extension elements? I think the answer to =20 this is actually that servers often do not and should not be required =20= to do so. That makes it hard for clients to extend AtomPub's syntax =20 in ways that other clients will understand but servers don't care =20 about. Consider the consequences: when some enterprising client =20 developer decides to do something cool and useful and encounters =20 servers that don't store their metadata in the obvious place, the =20 client developer is going to quickly work around that by storing in =20 some unobvious place. For example in HTML comments in the atom entry =20= content, or microformats, etc. Is that all cool? (Aside: an example of clients working around servers like this is =20 that some WebDAV servers in the very early days didn't actually allow =20= clients to PROPPATCH custom properties as the authors clearly =20 intended. Some client wanted to put extra structured information on =20 a resource when it was locked. Instead of putting it in properties, =20 since that didn't work reliably, the client instead put it in the =20 LOCK entry's "owner" element! Of course that didn't reliably =20 interoperate either because some servers overwrote the "owner" =20 element with authoritative information -- the lock's actual owner as =20 known by the server. So the workaround solution was also harmful to =20 interoperability, only it was discovered after the client had shipped.) Workspaces What are workspaces? I would like to see a definition. I believe I =20 understand that basically, a workspace corresponds to a single =20 published feed; that a workspace contains the collections with the =20 content authored for that feed. I know the WG discussed this so =20 maybe I can suggest wording at some point or simply register my vote =20 for saying what it *is*. Besides the definition, I also wonder about workspace titles. That =20 seems redundant with the title of the entry collection and possibly =20 also the title of the feed (inside the main feed document). Is there =20= any understanding of some of these values being identical, or any =20 understanding of what different purpose they serve if they're not =20 identical? OPTIONS response HTTP is unclear about where PUT and POST show up in Allow headers. =20 WebDAV ran into this as an interoperability problem -- some clients =20 assumed that if they didn't see PUT in the Allow header for a =20 collection, they couldn't write to that collection (the client might =20 be checking for permissions or policy, having already established =20 that the server was a WebDAV server but not certain if PUT would be =20 allowed to this particular place). Some servers had PUT in the Allow =20= header value for a collection, some servers didn't, based on the =20 literal reading that you couldn't actually PUT straight to a =20 collection URL. Clients had to end up with the OPTIONS Allow: header =20= response being useless in this case. With somebody else's hindsight, =20= Atom doesn't have to leave this ambiguous for the special kinds of =20 resources it defines... Cookie support, sessions, authentication Is there an assumption that clients MUST support cookies? without =20 such a requirement explicitly stated, some clients won't, for =20 reasonable security concerns. Instead, is there an assumption that =20 clients MUST repeat authentication headers with each request? Or =20 will servers effectively end up constantly "reminding" clients =20 (through 401 errors) to authenticate? This might seem obvious but it =20= definitely differs from regular HTTP practice where clients =20 authenticate once and then stop sending authentication information =20 automatically and it just works because of cookies. Also we'd =20 experienced this as an interoperability problem in WebDAV =20 interoperability tests where some server implementors insisted that =20 certain WebDAV clients were completely broken in not supporting cookies. Are there assumptions that sessions will be maintained through =20 persistent connections? I believe there should be none. That is, if =20= you're a client implementor thinking that the first request will =20 contain authorization and subsequent requests on the same connection =20 have no authorization, think again. ANCHOR sections It's not clear to me that the RFC Editor will know what to do with =20 all the [[anchor... ]] sections. Most difficult of all, "anchor37" =20 says "incomplete section". For the rest, sometimes the RFC Editor =20 may need to know what to replace with what on publication. I'm sure =20 the doc editors know what they meant but I personally was left guessing. Lisa= --Apple-Mail-12-279554216 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Despite the = length of these comments, I feel this specification is nearly there and = I look forward to seeing its completion.=A0 There are enough questions = on this version, however, that it's worthwhile pointing them out so that = the WG can discuss before the document goes out for wider review (IETF = last call), to other people who haven't been immersed in the discussions = thus far and thus don't share the same unstated assumptions.=A0 If the = unstated assumptions are turned into definitions or requirements in the = document we'll get much better IETF and then IESG review.=A0 Similarly, = if undefined behaviors are explicitly flagged as "undefined", then = everybody is warned about nasal demons <http://catb.org/jargon/html/N/nasal-demons.html> -- a spec that doesn't flag undefined behavior often leads to the = reader of the spec filling in unconsciously with their own assumptions = (I see that over and over and over again now that I'm reviewing so many = documents and discussing reviews with others).



=A0- To an = outsider or newcomer -- including me even though I've been following = discussions closely for a while -- there's a part of the Atom model = that's subtle but important to understand.=A0 Consumers of Atom feeds = are supposed to look at the regular feed document, whereas publishers of = Atom feeds are supposed to look at other, different resources to see how = to edit or create posts.=A0 Publishers effectively look at a different = feed than users do, one with extra metadata (the rel=3D"edit" links).=A0 = It's a different model than that of WebDAV or IMAP, because rather than = have the client specify which metadata it's interested in, the server = offers two choices with different addresses.=A0 I believe it would be = useful to cover that part of the model upfront in addition to the other = useful stuff already there.









=


Multiple = formats are not sufficiently defined -- e.g. JPG and PNG versions of an = image resource.=A0 Format negotiation is hard. =A0I found guidance for = how to select among different "edit-media" link relations depending on = format and language, but I found no guidance on how to create multiple = versions.=A0 =A0If there's no guidance to clients or servers how to do = it (would the client create multiple resources in different formats? = could the server automatically do it as variants? could the server = automatically do it as multiple resources, and would all formats be = therefore listed?), it's probably worth considering whether there's = possible interoperability harm here.=A0 I can imagine clients creating = alternate-format versions quite successfully because the operations = would be explicit, but when I imagine how servers would go about it, I = can easily see ways it could go wrong (e.g. creating new URLs for = resources that are invisible to the media collection, having multiple = URLs in locations where clients expect only one).

I think there = may be a very basic confusion here -- in my head or in the document or = both -- about what the "edit-media" link relation does and is for.=A0 = When I read the text it seems to offer the possibility for multiple = formats for a single media resource, as suggested by the text: "If a = client=A0encounters multiple "edit-media" link relations in an entry = then it=A0SHOULD choose a link based on the client preferences for type = and=A0hreflang".=A0 However, when I try to think about how a client = would create a post with a totally independent set of JPG images (e.g. = one of the Eiffel Tower, one of the Louvre and one of the Arche de = Triomphe), the "edit-media" link relation also seems to have relevance. = Which is it or both? (and as always, who is responsible for filling it = in or removing it when new media resources are created or = destroyed?)

Thomas Broyer said in email July 24 that=A0=A0"Having = the=A0Content-Location value equal to the Location one tells the client = that=A0the response body is a representation of the newly created = resource".=A0 =A0This is a subtle reading of HTTP and, if it's true,=A0 = I want to make sure that implementors understand this without having to = read the mailing list.=A0 The spec reads "=A0the response=A0from the = server SHOULD contain a Content-Location header that=A0contains the same = character-by-character value as the Location=A0header."=A0 If the = response from the server does not contain both headers identical, what = should the client conclude?=A0 I think this is one of those SHOULD = recommendations where the consequence of it not being a MUST need to be = considered.=A0 Possibly the spec needs to say under what conditions the = server would do otherwise; possibly the spec should say what the client = knows, or does not know, or must do, if the server does = otherwise.











You can see = that I lean more towards the "explain confusing things" side and "add = more stringent requirements" than to the "it's already written elsewhere = side" by peeking at section 8.2 of CalDAV <http://www.ietf.org/internet-drafts/draft-dusseault-cald= av-15.txt>.=A0 A mostly-explanatory guidelines section = helps clients quickly understand a clear path towards synchronization, = and new requirements for supporting ETags make things easier for what = is, after all, a more limited use case of HTTP (calendaring) than the = general case.=A0 If HTTP synchronization in authoring cases were clearly = defined and had not lead to years of arguments since the last HTTP = update, I would probably feel differently about just silently relying on = the mechanisms in HTTP.=A0=A0

In any case, I have very specific brief suggestions = to cover synchronization so that it's implemented more successfully than = not.
- Consider adding a brief section = offering clients non-normative guidelines on synchronization.=A0 It = doesn't have to limit server behavior so much as point out with green = and red lights where the fairway is (mixing transportation and golfing = metaphors in my head)
- Make a = few requirements of servers to avoid some of those HTTP ambiguities.=A0 = For example:
"The ETag or Last-Modified values = for a member resource MUST change when any metadata in the resource = changes, as well as text/content, and this includes "next" and "last" = link relation values. =A0The ETag or Last-Modified values of a member = resource MUST NOT change solely because an associated other resource = (e.g. the media resource being an associated resource to the media link = entry resource) changed.=A0 "=A0

More open questions that might be related to synch = or might have relevance even for clients that don't do full = synch:
- What is the relationship, if = any, between the "atom:updated" value and the HTTP "Last-Modified" = value.=A0 Can the "atom:updated" value ever be later (greater) than the = "Last-Modified" value?=A0 I believe it can be the same or earlier, but = the spec doesn't disallow the broken case.
-=A0Is it = clear whether the client MUST GET the entry after modifying it in order = to have an accurate offline cache?=A0 (this was mentioned in a post by = Broyer Jul 13, but not in the document).=A0 I believe this is made clear = already for the cases of getting the feed and also for POST/create, but = not for PUT/modify.
- Am I = correct that the general assumption is that id's are there to see what = entries are new, and URLs are there to see where to get them?=A0 That = may mean that URLs could change, for a given ID -- Perhaps a feature to = change the slug name of a image after attaching it.=A0 Is that = theoretically possible?

There are also efficiency considerations.
- The spec could require that = servers MUST return either the ETag, or the Last-Modified value, in any = successful POST or PUT response.=A0 I personally favour this so that = clients can rely on it, though obviously other opinions are valid = here.
- I really liked the idea of = putting ETag in the author's feed, as discussed on the list but not = appearing in the document, again for efficiency.=A0=A0
Certainly, the spec could ignore these = considerations for now.=A0 However, I have noted that many client = implementations choose a single way to implement their logic that can be = relied upon if a reliable approach is available, rather than respond = differently to different implementations.=A0 Thus, I predict that if = some servers implement more-efficient synchronization and others don't, = clients will behave as if they're always talking to the less-efficient = servers. The more-efficient servers will find it difficult to achieve = better scalability through synch efficiency improvements because clients = have already implemented reliable but inefficient synchronization and = don't have reason to add a second logic path for the more-efficient = servers.=A0=A0

Internationalization

How are = categories compared? Case-sensitive, insensitive, according to which = language? Would the categories=A0"donn=E9" and "donne" map to the same = category as "Donne" and "DONNE"?=A0I believe it's currently up to the = server, which means unpredictable behavior from the point of view of = clients. See=A0http://www.ietf.org/internet-drafts/draft-newman-i18n-co= mparator-14.txt, which has passed IESG Evaluation except for = some IANA actions.=A0 =A0This is a danger area for any draft going = before the IESG which looks carefully at i18n these days.

How do lang = tags inside the document relate to Content-Language information in = headers? Does the most granular override the other possible values?=A0 = What about when client provides to server? Does the server ignore or = handle?

Other

The requirements for the link relations "next", = "previous", "first" and "last" aren't as rigorous as for "edit" and = "edit-media" link relations.=A0 Also they're defined quite separately -- = I kind of thought that all the link relation types could be usefully = defined in one section but if the editors prefer a different = organization that's fine.=A0 But; is it OK if the resource pointed to by = one of these link relations is on another server, in another feed, is a = different kind of resource than you might normally expect, etc... ?=A0 I = think the normal cases for these link relations are well-understood but = not necessarily what a client should do if it encounters abnormal = cases.

Discovering feed reading URL

A very minor = feature request for the introspection document: it SHOULD contain the = public or published read-only feed URL of the blog (Tim suggests using = link rel=3D"alternate" type=3D"application/atom+xml", although I'm not = sure that makes it sufficiently clear what it's for).=A0=A0 This so that = my blog editing tool can show me not only all the entries and media = resources (all discoverable from the introspection doc already) but also = where the blog is published, so that I can copy that link to my friends = when telling them about my blog.

Extensions

When the client puts extension elements in a MER, = MUST the server store those unrecognized extension elements?=A0 I think = the answer to this is actually that servers often do not and should not = be required to do so.=A0 That makes it hard for clients to extend = AtomPub's syntax in ways that other clients will understand but servers = don't care about.=A0 Consider the consequences: when some enterprising = client developer decides to do something cool and useful and encounters = servers that don't store their metadata in the obvious place, the client = developer is going to quickly work around that by storing in some = unobvious place.=A0 For example in HTML comments in the atom entry = content, or microformats, etc.=A0 Is that all cool?=A0=A0

(Aside: an = example of clients working around servers like this is that some WebDAV = servers in the very early days didn't actually allow clients to = PROPPATCH custom properties as the authors clearly intended.=A0 Some = client wanted to put extra structured information on a resource when it = was locked.=A0 Instead of putting it in properties, since that didn't = work reliably, the client instead put it in the LOCK entry's "owner" = element!=A0 Of course that didn't reliably interoperate either because = some servers overwrote the "owner" element with authoritative = information -- the lock's actual owner as known by the server.=A0 So the = workaround solution was also harmful to interoperability, only it was = discovered after the client had shipped.)=A0


What are workspaces?=A0 I would like to see a = definition.=A0 I believe I understand that basically, a workspace = corresponds to a single published feed; that a workspace contains the = collections with the content authored for that feed.=A0 I know the WG = discussed this so maybe I can suggest wording at some point or simply = register my vote for saying what it *is*.=A0=A0

Besides the = definition, I also wonder about workspace titles.=A0 That seems = redundant with the title of the entry collection and possibly also the = title of the feed (inside the main feed document).=A0 Is there any = understanding of some of these values being identical, or any = understanding of what different purpose they serve if they're not = identical?

OPTIONS response

HTTP is unclear about where PUT and POST show up in = Allow headers.=A0 WebDAV ran into this as an interoperability problem -- = some clients assumed that if they didn't see PUT in the Allow header for = a collection, they couldn't write to that collection (the client might = be checking for permissions or policy, having already established that = the server was a WebDAV server but not certain if PUT would be allowed = to this particular place).=A0 Some servers had PUT in the Allow header = value for a collection, some servers didn't, based on the literal = reading that you couldn't actually PUT straight to a collection URL.=A0 = Clients had to end up with the OPTIONS Allow: header response being = useless in this case.=A0 With somebody else's hindsight, Atom doesn't = have to leave this ambiguous for the special kinds of resources it = defines...

Cookie support, sessions, authentication

Is there an = assumption that clients MUST support cookies?=A0 without such a = requirement explicitly stated, some clients won't, for reasonable = security concerns.=A0 Instead, is there an assumption that clients MUST = repeat authentication headers with each request?=A0 Or will servers = effectively end up constantly "reminding" clients (through 401 errors) = to authenticate?=A0 This might seem obvious but it definitely differs = from regular HTTP practice where clients authenticate once and then stop = sending authentication information automatically and it just works = because of cookies.=A0 Also we'd experienced this as an interoperability = problem in WebDAV interoperability tests where some server implementors = insisted that certain WebDAV clients were completely broken in not = supporting cookies.

Are there assumptions that sessions will be = maintained through persistent connections?=A0 I believe there should be = none.=A0 That is, if you're a client implementor thinking that the first = request will contain authorization and subsequent requests on the same = connection have no authorization, think again.

ANCHOR = sections

It's not clear to me that the RFC Editor will know = what to do with all the [[anchor... ]] sections.=A0 Most difficult of = all, "anchor37" says "incomplete section".=A0 For the rest, sometimes = the RFC Editor may need to know what to replace with what on = publication.=A0 I'm sure the doc editors know what they meant but I = personally was left guessing.

Lisa
= --Apple-Mail-12-279554216-- From owner-atom-syntax@mail.imc.org Tue Oct 17 19:47:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyeJ-0000s9-1W for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 19:47:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZyUr-0006nm-WE for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 19:37:27 -0400 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 k9HN7bBG050984; Tue, 17 Oct 2006 16:07: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 k9HN7bb8050983; Tue, 17 Oct 2006 16:07: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 sam.opera.com (sam.opera.com [193.69.113.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HN7Xma050976 for ; Tue, 17 Oct 2006 16:07:34 -0700 (MST) (envelope-from fora@annevankesteren.nl) Received: from id-c0020.oslo.opera.com (pat.opera.com [193.69.113.22]) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k9HN7R2L017837; Tue, 17 Oct 2006 23:07:29 GMT Date: Wed, 18 Oct 2006 01:07:27 +0200 To: "James M Snell" , "James Holderness" Subject: Re: [atom-syntax] Atom bidi From: "Anne van Kesteren" Cc: atom-syntax@imc.org Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <4534F37E.4000904@gmail.com> <45352FDE.7020709@gmail.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <45352FDE.7020709@gmail.com> User-Agent: Opera Mail/9.02 (Win32) 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 Tue, 17 Oct 2006 21:32:46 +0200, James M Snell wrote: > 2. Look for the xhtml:dir attribute There's no such thing. (Except perhaps with this new XHTML Modularization madness, but that's best ignored.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Oct 17 19:55:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZymo-0008V5-NG for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 19:55:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZymj-0002eY-Ak for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 19:55:54 -0400 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 k9HNVt32052420; Tue, 17 Oct 2006 16:31: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 k9HNVt5b052419; Tue, 17 Oct 2006 16:31: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 ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9HNVgwK052400 for ; Tue, 17 Oct 2006 16:31:50 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] ([203.30.247.118] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0007052791 for ; Wed, 18 Oct 2006 09:31:40 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 18 Oct 2006 09:31:37 +1000 Subject: Re: AD Evaluation -- extensions From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> 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 k9HNVtwK052414 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 k9HNVt32052420 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On 18/10/06 8:07 AM, "Lisa Dusseault" wrote: > Extensions >=20 > When the client puts extension elements in a MER, MUST the server store= those > unrecognized extension elements?=A0 I think the answer to this is actua= lly that > servers often do not and should not be required to do so.=A0 That makes= it hard > for clients to extend AtomPub's syntax in ways that other clients will > understand but servers don't care about.=A0 Consider the consequences: = when some > enterprising client developer decides to do something cool and useful a= nd > encounters servers that don't store their metadata in the obvious place= , the > client developer is going to quickly work around that by storing in som= e > unobvious place.=A0 For example in HTML comments in the atom entry cont= ent, or > microformats, etc.=A0 Is that all cool?=A0=A0 This issue also has implications on what extensions are passed through to the published feed ... a client might insert some extension metadata they want published (eg. geo-coordinates), and a client might insert some extension metadata they only want visible within the collection feed (eg. editor workflow comments) ... with the understanding also that if the ser= ver actually understands a particular extension it might result in extensions being added/modified outside of the bucket (eg. resulting in lots of elements being added) We did at one time discuss providing a bucket container specifically for = the latter, with the assumption that extensions outside the bucket are data elements meant for publication. Having a bucket container would make life simpler for server implementations -- just store everything as an xml blo= b, the same as they do for atom:content[@type=3Dxhtml]. Lisa, would that help? e. From owner-atom-syntax@mail.imc.org Tue Oct 17 19:59:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZypt-0001jG-Gb for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 19:59:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZypr-0002zY-U8 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 19:59:05 -0400 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 k9HNf301053150; Tue, 17 Oct 2006 16:41: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 k9HNf3Hq053149; Tue, 17 Oct 2006 16:41: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HNf0Oj053131 for ; Tue, 17 Oct 2006 16:41:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so86496wxc for ; Tue, 17 Oct 2006 16:40:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=g9VkJQkubBbEOZ0F/QQCK5K3EQAz5b3VnZ+y/rmXiMCla/BGS6yIITTI41uL+U5o1WvHHy3vnzN0jKPrTTW1t+ncvphQdZ3zpPSnmyBQlTF97AAW8aq+MEed8RWj0RKmQwlNN1Ru18+cvp5Uv8lOXprRnI/W+DaNl6Jd8vvOSFQ= Received: by 10.70.129.2 with SMTP id b2mr14575979wxd; Tue, 17 Oct 2006 16:40:59 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 5sm361883wrh.2006.10.17.16.40.56; Tue, 17 Oct 2006 16:40:58 -0700 (PDT) Message-ID: <45356A03.7060601@gmail.com> Date: Tue, 17 Oct 2006 16:40:51 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Lisa Dusseault CC: atom-protocol Protocol , atom-syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> In-Reply-To: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> Content-Type: text/plain; charset=ISO-8859-1 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 k9HNf301053150 X-Spam-Score: 1.1 (+) X-Scan-Signature: bc3b4a0e61e6c2546ab80acca7fc79df Some comments... largely written up in terms of what my working assumptions have been. We'll see how things match up with what others on the list are thinking. - James Lisa Dusseault wrote: > [snip] > *High-level comments, summarizing comments* >=20 > - The mechanism for creating a media resource and a media link entry i= n > response to a single POST conflicts with at least one statement > elsewhere in the draft, and has no example. This is one of those cases > where I personally had some assumptions (that not every media resource > had its own media link entry if the media resource had been created > manually) that weren't ever quite cleared up by the spec. If the client > CAN create a media resource without also creating a media link entry, > that should be a separate example. My assumption: a client cannot create a media resource without also creating a media link entry. When I POST a media resource to a collection, a media link entry is *always* created. > - Overall, the responsibility model needs to be slightly better > defined. E.g. we know the server is responsible for choosing a URL for > new entries; it's not clear who's responsible for cleaning up linked > entries if a user ever needs to clean up historical entries. Atom > sometimes seems to split the responsibility, and those are the most > complicated cases. More examples below as it's probably more useful to > discuss specifics. My assumption: the server is ultimately responsible for everything. If the server wishes to give me a mechanism for deleting old entries, then it's the server's responsibility for ensuring that the results of that operation are consistent and correct. > - To an outsider or newcomer -- including me even though I've been > following discussions closely for a while -- there's a part of the Atom > model that's subtle but important to understand. Consumers of Atom > feeds are supposed to look at the regular feed document, whereas > publishers of Atom feeds are supposed to look at other, different > resources to see how to edit or create posts. Publishers effectively > look at a different feed than users do, one with extra metadata (the > rel=3D"edit" links). It's a different model than that of WebDAV or IMA= P, > because rather than have the client specify which metadata it's > interested in, the server offers two choices with different addresses.=20 > I believe it would be useful to cover that part of the model upfront in > addition to the other useful stuff already there. >=20 My assumption: The separation between "subscription feeds" and "collection feeds" is not always clear. There are at least two deployed implementations I am aware of that use the same feeds for both and I'm currently working on a third. In Google's new Blogger Beta, for instance, the subscription feed is also the collection feed. I believe that any assumption that the subscription and collections feeds will always be different is incorrect and dangerous. > *Creating resources* >=20 > Explicit result of POST, section 4.=20 >=20 > Are there zero, one or more resources created with a POST? There's a > line at the top of section 4 which says that "POST is used to create a > new, dynamically-named, resource". However, that implies ONE, whereas > with media entries, a POST could create TWO resources. I believe a > successful POST request as described here MUST either result in one or > two resources, never zero, and never 3 or more (in the absence of > extensions). My assumption: A POST could actually create any number of resources. For instance, when I POST an entry to my weblog, at least two resources will be created (the editable entry and the HTML "permalink" page) and several others will be modified (the collection feed, the blog index page, archive pages, etc). Similarly, when I POST a media resource, I would expect that multiple resources could be created. How many resources are created/modified is up to the server implementation. From the client's point of view, there are only two resources that are of immediate concern: the atom:entry and the collection feed. At the very least, A successful POST should result in the creation of the atom:entry. No other assumptions can be made beyond that. >=20 > What is the expected behavior of seeing a POST to an entry URL (rather > than a collection URL)? I see that this is currently undefined; it may > be worth stating that to warn clients. (I'm pretty indifferent on this > one, as in this case I can't see any obvious harm in different server > behaviors existing, if un-warned clients try it intentionally without > knowing the results. The only possible harm is if clients got confused= , > did a POST to an entry URL when a collection URL was intended, and the > server does a success response which creates new resources or modifies > existing resources in a way the client did not expect. An error > response would certainly be harmless for this undefined case but a > success response could be real interesting.) >=20 My assumption: This has always been left undefined. There are at least two different implementations that do different things with the POST operation on an entry. GData, for instance, supports using POST as a way of working around PUT/DELETE blocking issues. IBM's OpenActivities uses POST, in part, to support a variety of extended operations such as undelete. Eventually, conventions for the use of POST on an Edit URI may emerge. For now, it's best to leave it undefined. > Creating entries with multiple media resources >=20 > It's never explained how a client would go about creating a feed entry > with a number of media resources. I imagine that it could be iterative= ; > a client could create any of the resources at any time, and at any time > after creating the feed entry, use PUT to update the feed entry to link > to new media resources. I assume -- though I didn't see it stated in > the document -- that it's the client's responsibility in almost all > cases to put links in the feed entry to point to the media resources, > otherwise the media resources are unlinked (effectively hidden to > readers). =20 >=20 My assumption: The relationship between a media link entry and a media resource is always 1-to-1. If I want an entry to point to multiple media resources, then I would create one media link entry for each media resource, then create a separate entry that points to each of the individually created media resources. e.g., entry1 --> pic1 entry2 --> pic2 entry3 --> pic3 entry4 --> pic1 --> pic2 --> pic3 Entries 1, 2 and 3 will always point to their respective media resources (using atom:content/@src). > The exception to this general process is if the client first uses POST > to create both the media resource and the "Media Link Entry" in one go.= =20 > In this case, can the "Media Link Entry" (MLE) be transformed to a > regular "Member Entry Resource" (MER)? I thought it would be possible, > but discussed just a bit with Tim today and he says no, so there you > have two different readings of the spec. I guess a related question is > what would happen if a client does a PUT of media content to an entry > resource, or entry content to a media resource. =20 >=20 My assumption: I had originally wanted the ability to change "MLE" into a "MER" but the general consensus of the WG seemed to be leading in the other direction. Once a media link entry is created, it cannot be changed into some other kind of thing. I personally think that's bogus, but... Regarding what would happen if a client does attempt to change the type of resource, that's undefined. In my current implementation, the new content would be silently discarded, which is bogus. I'll likely change the behavior so that the request is rejected. > It's not clear to me whether a linked media entry is always listed in > the metadata or not. =20 My assumption: Yes > - When one or more "edit-media" link relations appear, who has been > responsible for putting them there?=20 My assumption: the Server > - When a media resource is deleted, who is responsible for removing the > media resource link from the MLE? My assumption: the Server. When the media resource is deleted, the associated MLE SHOULD also be deleted. > - Section 4 says that the MLE contains the metadata for a Media > Resource, but that seems to only assume a single Media Resource. In th= e > case of multiple Media Resources which the user intends to link into a > single post, it's unclear to me whether there's one MLE for every Media > Resource, or one MER for all the Media Resources created, or some other > situation. Again, in quick discussion with Tim, he says there is one > Media Link Entry per Media Resource. I can see how that would work but > that was not at all my understanding before the discussion! >=20 See above. > This document would benefit greatly from further examples: > 1. An example of creating a MLE and MR in a single POST; the request, > response and the result (resource URLs) described. Section 9.6.2 already contains such an example. > 2. An example of modifying a MER to contain a new image or other media > resource link: the request(s), possibly the responses (if it's > interesting, it may not be), and definitely the result. Agree. This would be helpful. > 3. An example of modifying a MER to change metadata (e.g. category or > adding a new link relation element or both); possibly a failed request > example would be even more interesting than a successful one. >=20 Agree. > Can a client modify an entry to contain a link relation element in the > following cases: > - To result in an "edit" or "edit-media" link relation, where the > resource represented does not meet the requirements in section 11.1 or = 11.2? > - To result in an "edit" link relation that actually points to a media > resource, or a "edit-media" link relation that actually points to a MER= ?=20 My assumption: the server is responsible for adding the edit and edit-media links. Clients are not allowed to modify these values. > - To point to a resource on a different server entirely?=20 > - To point to a valid media resource or MER that happen to be in a > different collection than the one normally used for this feed? > - Will some servers forbid adding a link relation element entirely? Is > it important for the client to know that that will always be forbidden > for that server -- can it detect the "always forbidden" case separately > from the "this particular edit is forbidden" case? My assumption: the decision is ultimately up to individual server implementations, but in general clients should be allowed to add/edit all link relations other than the edit and edit-media links. It is unlikely, however, that your typical blog implementation of APP would allow a client to modify the alternate link relation. > Which of these are errors, and if so how is the error handled? Which o= f > these MUST the server allow and handle? I understand there may be some > need for flexibility here. Perhaps it's just standardized error > messages required here. For example, if there are some servers which > allow a given link relation to point to another server, and some server= s > which do not allow, how would the servers which do not allow respond > with a sufficiently specific error, so that the client can avoid trying > the same thing again? >=20 My assumption: different servers are going to have different requirements. This needs to remain as flexible as possible. A standard way of reporting errors would be helpful, but trying to dictate too much in this area will just lead to headaches. >=20 > Multiple formats/langs for media resources >=20 > Multiple formats are not sufficiently defined -- e.g. JPG and PNG > versions of an image resource. Format negotiation is hard. I found > guidance for how to select among different "edit-media" link relations > depending on format and language, but I found no guidance on how to > create multiple versions. If there's no guidance to clients or server= s > how to do it (would the client create multiple resources in different > formats?=20 Yes. > could the server automatically do it as variants?=20 Yes. > could the server automatically do it as multiple resources, and would all formats > be therefore listed?), Yes. > it's probably worth considering whether there's > possible interoperability harm here. =20 The behavior is ultimately up to the server. No normative behavior should be specified (largely because we're not yet sure what all folks will actually want to do). > I can imagine clients creating > alternate-format versions quite successfully because the operations > would be explicit, but when I imagine how servers would go about it, I > can easily see ways it could go wrong (e.g. creating new URLs for > resources that are invisible to the media collection, having multiple > URLs in locations where clients expect only one). >=20 Again, it's the individual server implementations responsibility to keep all this straight. Yes, there is a good possibility that some servers will screw it up, but that's ok. > I think there may be a very basic confusion here -- in my head or in th= e > document or both -- about what the "edit-media" link relation does and > is for. When I read the text it seems to offer the possibility for > multiple formats for a single media resource, as suggested by the text: > "If a client encounters multiple "edit-media" link relations in an entr= y > then it SHOULD choose a link based on the client preferences for type > and hreflang". However, when I try to think about how a client would > create a post with a totally independent set of JPG images (e.g. one of > the Eiffel Tower, one of the Louvre and one of the Arche de Triomphe), > the "edit-media" link relation also seems to have relevance. Which is i= t > or both? (and as always, who is responsible for filling it in or > removing it when new media resources are created or destroyed?) >=20 My assumption: the edit-media link relation is primarily intended to allow media resources to be edited independently of their associated Media link entry. The fact that multiple edit-media links may be present is secondary and orthogonal to this main purpose. > Thomas Broyer said in email July 24 that "Having the Content-Location > value equal to the Location one tells the client that the response body > is a representation of the newly created resource". This is a subtle > reading of HTTP and, if it's true, I want to make sure that > implementors understand this without having to read the mailing list.=20 > The spec reads " the response from the server SHOULD contain a > Content-Location header that contains the same character-by-character > value as the Location header." If the response from the server does no= t > contain both headers identical, what should the client conclude? I > think this is one of those SHOULD recommendations where the consequence > of it not being a MUST need to be considered. Possibly the spec needs > to say under what conditions the server would do otherwise; possibly th= e > spec should say what the client knows, or does not know, or must do, if > the server does otherwise. >=20 My assumption: IMHO, this recommendation no longer unnecessary given that our recent decision to require that the Location header always point to the Edit URI of the resource created. I'd prefer that it be removed. > *Deleting Resources* >=20 > In the case of an entry that points to multiple media resources, can th= e > server delete all those media resources and their MLEs? (I think not).= =20 > If a client issues a DELETE to a media resource, is its MLE deleted? > (The spec covers the opposite case already when a client issues a DELET= E > to an MLE.) =20 My assumption: If a client DELETE's a MLE, it's associated media resource SHOULD be deleted. If the client DELETE's the media resource, the MLE SHOULD be deleted. If the client DELETE's an entry that links to a media resource in any other way (e.g. there is some other kind of link relation or an img tag in html content, etc) then the "correct" behavior is up to the server. >=20 > Can collections be DELETEd? It's fine for servers to allow or no, but > if servers don't support, what error to use. >=20 My assumption: It's up to the server. 405 Method Not Allowed. > *Editing resources* >=20 > Overall, the process for editing a resource is not entirely clear. I > find the description of creating a resource (POST), and what the server > can accept, ignore or reject, more clear than the description of editin= g > a resource (PUT) . For example, there's normative text in section 9.2.= 1 > (an example) relative to creating resources and handling metadata, but > that text isn't duplicated for editing resources or obviously apply to > editing resources. Thus:=20 > - Can the client change the category? (probably yes; MUST the server > allow?) Generally Yes. It's up to the server. > - Can the client change the atom:id? (probably never) No. > - Can the client change the "updated" value to be some time in the > future? Some time long ago? Or are there only two non-error changes -- > "now" or "the previous value"? MUST the server accept the value if it'= s > the same as the previous value? Or can there be servers that always > ignore "updated" values from clients? (and if so, is it important for > the client to know that the server does this) Generally No, but it's up to the server. For the most part, servers should and will manage the value of atom:updated themselves. > - Can the client change the set of link relations? (probably yes; but > does that include "edit" and "edit-media" link relations only or also > first/previous/next/last link relations?) > In general the possible edits need to be covered to consider whether th= e > server MUST allow these kinds of edits, or MAY, and if refused, what > error for what reason. Generally Yes, with the exception of edit and edit-media and possibly alternate, all of which the server will usually manage. > [snip] > The spec says "The value of atom:updated is only changed when the chang= e > to a member resource is considered significant. " The use of passive > voice obscures who does what here. When the client doesn't suggest a > value for "atom:updated", does the server provide one, and if so, how > does the server know what is "significant"? I thought it would always > be the client suggesting values, but Tim says that the server controls > atom:updated which could imply that the client doesn't even need to > suggest values. See above about whether the server MUST accept certain > values for "updated", or more likely, MUST NOT accept suggested values > for "updated" when they're clearly wrong (e.g. this entry was last > updated on October 16, 1906). >=20 My assumption: Tim is correct. The server controls atom:updated. While the client is required to provide a valid atom:updated element, the server can (and in most cases will) ignore that value. > Can a server ever ignore part of an edit and successfully process the > rest? For example, the server receives a PUT request that tries to edi= t > the text of a MER and includes a new category value, the server accepts > the new text but silently ignores the category value. I suggest the > answer would be MUST NOT silently ignore suggested changes, particularl= y > since there's no way in a PUT response to say "here's what the server > actually stored". It may be my opinion differs here from that of the > WG. I find silently ignoring input to be scary. >=20 My assumption: Yes, it's up to the server. In general, servers should not make a habit of applying partial updates unless the client is aware that data loss could happen. Current implementations handle this differently. > *Synchronization* >=20 > I predict that some AtomPub authoring clients will attempt to > synchronize: to maintain an offline copy of the feed including all its > MERs and media resources, and to keep that offline copy up-to-date.=20 > Some will probably even allow offline authoring of new posts, and offer > to synchronize when the client next goes online -- because of the > possibility of multiple authors, this may mean at times that the client > would download new entries created by other authors, upload new entries > created offline, and reconcile its offline copy of feed documents. >=20 > Because authoring clients will attempt to do this based on Last-Modifie= d > and ETag -- after all, the functionality is all there in some form or > another -- the spec needs a little more clarity on how the client can > rely on this working. Otherwise, some servers may omit features that > these authoring clients require, or implement them oddly. While I woul= d > never suggest repeating all the requirements from other specs (in this > case HTTP), there are cases where clarity and interoperability are > greatly improved by at least referencing explicitly requirements from > HTTP. It's also possible to add new requirements based on features in > HTTP, that apply to Atom servers alone. =20 >=20 I would be very happy to see some discussion of this in the spec, especially if it normatively required the use of ETags for offline synchronization. >[snip] > of HTTP (calendaring) than the general case. If HTTP synchronization i= n > authoring cases were clearly defined and had not lead to years of > arguments since the last HTTP update, I would probably feel differently > about just silently relying on the mechanisms in HTTP. =20 >=20 +1 > In any case, I have very specific brief suggestions to cover > synchronization so that it's implemented more successfully than not. > - Consider adding a brief section offering clients non-normative > guidelines on synchronization. It doesn't have to limit server behavio= r > so much as point out with green and red lights where the fairway is > (mixing transportation and golfing metaphors in my head) > - Make a few requirements of servers to avoid some of those HTTP > ambiguities. For example: > "The ETag or Last-Modified values for a member resource MUST change whe= n > any metadata in the resource changes, as well as text/content, and this > includes "next" and "last" link relation values. The ETag or > Last-Modified values of a member resource MUST NOT change solely becaus= e > an associated other resource (e.g. the media resource being an > associated resource to the media link entry resource) changed. "=20 +0.5. I would add that the ETag/Last-Modified values of a resource SHOULD NOT change solely because of non-significant changes to the infoset serialization of an entry (e.g. a different namespace prefix is used, or whitespace is added or removed, etc). I would also prefer that the ETag for a MLE change when it's associated media resource is updated. >=20 > More open questions that might be related to synch or might have > relevance even for clients that don't do full synch: > - What is the relationship, if any, between the "atom:updated" value an= d > the HTTP "Last-Modified" value. Can the "atom:updated" value ever be > later (greater) than the "Last-Modified" value? I believe it can be th= e > same or earlier, but the spec doesn't disallow the broken case. My assumption: There is no relationship. atom:updated should be treated as being entirely independent of Last-Modified. It might be reasonable, however, to define a relationship between Last-Modified and app:edited. > - Is it clear whether the client MUST GET the entry after modifying it > in order to have an accurate offline cache? (this was mentioned in a > post by Broyer Jul 13, but not in the document). I believe this is mad= e > clear already for the cases of getting the feed and also for > POST/create, but not for PUT/modify. My assumption: Yes. > - Am I correct that the general assumption is that id's are there to se= e > what entries are new, and URLs are there to see where to get them? Tha= t > may mean that URLs could change, for a given ID -- Perhaps a feature to > change the slug name of a image after attaching it. Is that > theoretically possible? My assumption: Yes. ID's also help to detect changes so that old entries are not flagged as new when insignificant updates are made. >=20 > There are also efficiency considerations. > - The spec could require that servers MUST return either the ETag, or > the Last-Modified value, in any successful POST or PUT response. I > personally favour this so that clients can rely on it, though obviously > other opinions are valid here. I'd prefer this. My current implementation always returns the ETag on the POST response. > - I really liked the idea of putting ETag in the author's feed, as > discussed on the list but not appearing in the document, again for > efficiency. =20 Are you referring to the app:etag element? > [snip] > *Internationalization* >=20 > How are categories compared? Case-sensitive, insensitive, according to > which language? Would the categories "donn=E9" and "donne" map to the s= ame > category as "Donne" and "DONNE"? I believe it's currently up to the > server, which means unpredictable behavior from the point of view of > clients. This is a separate issue that impacts RFC4287 in general more than it does APP specifically. My assumption has always been that categories are compared using case-sensitive, character-by-character analysis of the scheme and the term, regardless of language. Your four examples would each evaluate to different categories. > See http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14= .txt, > which has passed IESG Evaluation except for some IANA actions. This i= s > a danger area for any draft going before the IESG which looks carefully > at i18n these days. >=20 > How do lang tags inside the document relate to Content-Language > information in headers? Does the most granular override the other > possible values? What about when client provides to server? Does the > server ignore or handle? >=20 My assumption: yes, the most granular overrides. It's up to the server to ignore or handle with the preference between towards handling. > *Other* >=20 > The requirements for the link relations "next", "previous", "first" and > "last" aren't as rigorous as for "edit" and "edit-media" link > relations. Also they're defined quite separately -- I kind of thought > that all the link relation types could be usefully defined in one > section but if the editors prefer a different organization that's fine.= =20 > But; is it OK if the resource pointed to by one of these link relations > is on another server, in another feed, is a different kind of resource > than you might normally expect, etc... ? I think the normal cases for > these link relations are well-understood but not necessarily what a > client should do if it encounters abnormal cases. >=20 I've always been bugged by the underspecification of this section. Given that there is a separate Feed Paging spec that is nearing completion, I'd be very happy if paging were removed completely from the APP spec. > Discovering feed reading URL >=20 > A very minor feature request for the introspection document: it SHOULD > contain the public or published read-only feed URL of the blog (Tim > suggests using link rel=3D"alternate" type=3D"application/atom+xml", > although I'm not sure that makes it sufficiently clear what it's for). = =20 > This so that my blog editing tool can show me not only all the entries > and media resources (all discoverable from the introspection doc > already) but also where the blog is published, so that I can copy that > link to my friends when telling them about my blog. >=20 Using alternate links for feed discovery is a sufficiently well-known common practice. It would likely be fine. > Extensions >=20 > When the client puts extension elements in a MER, MUST the server store > those unrecognized extension elements? I think the answer to this is > actually that servers often do not and should not be required to do so.= =20 > That makes it hard for clients to extend AtomPub's syntax in ways that > other clients will understand but servers don't care about. Consider > the consequences: when some enterprising client developer decides to do > something cool and useful and encounters servers that don't store their > metadata in the obvious place, the client developer is going to quickly > work around that by storing in some unobvious place. For example in > HTML comments in the atom entry content, or microformats, etc. Is that > all cool? =20 It's up to the server. Google's GData, for instance, will reject entries that use unknown foreign markup. IBM's OpenActivities will silently dropped unknown markup. The implementation I'm working on currently will retain all unknown foreign markup. I'd prefer to leave this open. > [snip] > Workspaces >=20 > What are workspaces? I would like to see a definition. I believe I > understand that basically, a workspace corresponds to a single publishe= d > feed; that a workspace contains the collections with the content > authored for that feed. I know the WG discussed this so maybe I can > suggest wording at some point or simply register my vote for saying wha= t > it *is*. =20 >=20 No, a workspace is a purely organizational construct that will vary depending on context. For instance, services like GData could offer a service document with one workspace per service (e.g. Blogger, Calendar, Base, etc) or, an implementation could offer a service document with different workspaces segmented along other lines (e.g. "Private Collections" "Shared Collections", "Team Collections", etc). The intention is purely to provide a means of grouping related collections in a logical way. There is no correlation between a workspace and the number of available feeds. > Besides the definition, I also wonder about workspace titles. That > seems redundant with the title of the entry collection and possibly als= o > the title of the feed (inside the main feed document). Is there any > understanding of some of these values being identical, or any > understanding of what different purpose they serve if they're not ident= ical? >=20 Again, there is no correlation between a "Workspace" and a feed. A workspace title may be something like "James' Private Collections", which may consist of twenty six individual feeds each titled with a letter of the english alphabet. > OPTIONS response >=20 > HTTP is unclear about where PUT and POST show up in Allow headers.=20 > WebDAV ran into this as an interoperability problem -- some clients > assumed that if they didn't see PUT in the Allow header for a > collection, they couldn't write to that collection (the client might be > checking for permissions or policy, having already established that the > server was a WebDAV server but not certain if PUT would be allowed to > this particular place). Some servers had PUT in the Allow header value > for a collection, some servers didn't, based on the literal reading tha= t > you couldn't actually PUT straight to a collection URL. Clients had to > end up with the OPTIONS Allow: header response being useless in this > case. With somebody else's hindsight, Atom doesn't have to leave this > ambiguous for the special kinds of resources it defines... >=20 In my impl, the server will always report all of the operations that can be applied to a resource, regardless of whether the current user is allowed to use those methods. A collection, for instance, will always specify (at a minimum) the GET and POST methods. An Edit URI will always specify (at a minimum) the GET, PUT and DELETE methods. > Cookie support, sessions, authentication >=20 > Is there an assumption that clients MUST support cookies? without such > a requirement explicitly stated, some clients won't, for reasonable > security concerns. Instead, is there an assumption that clients MUST > repeat authentication headers with each request? Or will servers > effectively end up constantly "reminding" clients (through 401 errors) > to authenticate? This might seem obvious but it definitely differs fro= m > regular HTTP practice where clients authenticate once and then stop > sending authentication information automatically and it just works > because of cookies. Also we'd experienced this as an interoperability > problem in WebDAV interoperability tests where some server implementors > insisted that certain WebDAV clients were completely broken in not > supporting cookies. My assumption: the client should generally assume that auth headers should be sent with each request and that cookies are likely not supported. However, this is another case where the behavior is completely up to the server. >=20 > Are there assumptions that sessions will be maintained through > persistent connections? I believe there should be none. That is, if > you're a client implementor thinking that the first request will contai= n > authorization and subsequent requests on the same connection have no > authorization, think again. >=20 My asssumption: client's should not assume that connections will be persistent or that sessions will be maintained (or that a session even exists). Each request is independent of all others. Excellent feedback. Thanks for taking the time. - James From owner-atom-syntax@mail.imc.org Tue Oct 17 20:09:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyzX-0008Di-1x for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:09:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZyzV-0003jL-M6 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:09:03 -0400 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 k9HNmSHn053719; Tue, 17 Oct 2006 16:48: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 k9HNmS7P053718; Tue, 17 Oct 2006 16:48: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HNmROt053712 for ; Tue, 17 Oct 2006 16:48:27 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so88227wxc for ; Tue, 17 Oct 2006 16:48:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=aVhGhcPp72SZTnoGoFyncO0K97H3A7drgx3jPwixP+uRl6KioPn8P3fKI16Yat17lbuHKU7ey0jWWwDwj+/LXyfq8owtk+XZgFOWYCRJo94J6OZmSHWl6cb+hLVrZPRtkIHnh09HLcbENJzT9vvIPw/4xFM8MzKR10IoC5VTI60= Received: by 10.70.103.12 with SMTP id a12mr14735050wxc; Tue, 17 Oct 2006 16:48:26 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 7sm364546wrl.2006.10.17.16.48.25; Tue, 17 Oct 2006 16:48:26 -0700 (PDT) Message-ID: <45356BC6.5060005@gmail.com> Date: Tue, 17 Oct 2006 16:48:22 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Anne van Kesteren CC: James Holderness , atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45352FDE.7020709@gmail.com> In-Reply-To: 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: 7d33c50f3756db14428398e2bdedd581 I know there's no such thing :-)... which is precisely why the code I implemented is temporary and experimental :-). - James Anne van Kesteren wrote: > On Tue, 17 Oct 2006 21:32:46 +0200, James M Snell > wrote: >> 2. Look for the xhtml:dir attribute > > There's no such thing. (Except perhaps with this new XHTML > Modularization madness, but that's best ignored.) > > > --Anne van Kesteren > > > > From owner-atom-syntax@mail.imc.org Tue Oct 17 20:16:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz6j-0005Rw-AI for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:16:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZz6h-00040S-VC for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:16:29 -0400 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 k9HNu54O054855; Tue, 17 Oct 2006 16:56: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 k9HNu5xN054854; Tue, 17 Oct 2006 16:56:05 -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.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HNu4jX054848 for ; Tue, 17 Oct 2006 16:56:05 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so89991wxc for ; Tue, 17 Oct 2006 16:56:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=tbGJ/Fu6xYL99FDV007U7sg/AnSxXcp4T+aUHTLq+4OMfSFodMwHhoQ4TND6aqMr7A7OdyvpWAcEaEgyO7EOG2g2w/Tt0d+tchSWNTdOpLSfB8j0vYf0BrXbGOSX+LJPF5UtpLEqDiZ3M8amOmmu/er2rDDv1O5RegoZAaivJsY= Received: by 10.70.32.2 with SMTP id f2mr14767140wxf; Tue, 17 Oct 2006 16:56:03 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 29sm64336wrl.2006.10.17.16.56.01; Tue, 17 Oct 2006 16:56:02 -0700 (PDT) Message-ID: <45356D8F.4010802@gmail.com> Date: Tue, 17 Oct 2006 16:55:59 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: AD Evaluation -- extensions References: In-Reply-To: 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: e5ba305d0e64821bf3d8bc5d3bb07228 That "bucket" already exists in the form of the app:control element. ... ... ... ... - James Eric Scheid wrote: > [snip] > We did at one time discuss providing a bucket container specifically for the > latter, with the assumption that extensions outside the bucket are data > elements meant for publication. Having a bucket container would make life > simpler for server implementations -- just store everything as an xml blob, > the same as they do for atom:content[@type=xhtml]. > > Lisa, would that help? > > e. > > > From owner-atom-syntax@mail.imc.org Tue Oct 17 20:25:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzFX-0005JH-JT for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:25:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzFS-0004ZI-Pi for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:25:35 -0400 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 k9HNxbHM055155; Tue, 17 Oct 2006 16:59: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 k9HNxb6Q055154; Tue, 17 Oct 2006 16:59: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-omc1-s38.bay0.hotmail.com (bay0-omc1-s38.bay0.hotmail.com [65.54.246.110]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HNxarn055068 for ; Tue, 17 Oct 2006 16:59:37 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([207.46.9.149]) by bay0-omc1-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:59:31 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Oct 2006 16:59:31 -0700 Message-ID: Received: from 81.179.103.143 by BAY120-DAV11.phx.gbl with DAV; Tue, 17 Oct 2006 23:59:26 +0000 X-Originating-IP: [81.179.103.143] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <4534F37E.4000904@gmail.com> <45352FDE.7020709@gmail.com> <45356BC6.5060005@gmail.com> Subject: Re: [atom-syntax] Atom bidi Date: Wed, 18 Oct 2006 00:57:22 +0100 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.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 17 Oct 2006 23:59:31.0210 (UTC) FILETIME=[498BBEA0:01C6F248] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Well I'm glad somebody pointed it out because I certainly missed it. Anyway, for now I'm just checking for an unprefixed dir attribute. If and when RFC 4287 is ever updated I'll ammend my code accordingly. Regards James James M Snell wrote: >I know there's no such thing :-)... which is precisely why the code I > implemented is temporary and experimental :-). > > - James > > Anne van Kesteren wrote: >> On Tue, 17 Oct 2006 21:32:46 +0200, James M Snell >> wrote: >>> 2. Look for the xhtml:dir attribute >> >> There's no such thing. (Except perhaps with this new XHTML >> Modularization madness, but that's best ignored.) From owner-atom-syntax@mail.imc.org Tue Oct 17 20:33:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzMq-0000MX-Qg for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:33:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzMo-00057X-D0 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:33:08 -0400 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 k9I0Gsqe056409; Tue, 17 Oct 2006 17:16: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 k9I0GssT056408; Tue, 17 Oct 2006 17:16: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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I0GrDu056402 for ; Tue, 17 Oct 2006 17:16:53 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D4BA1422CF; Tue, 17 Oct 2006 17:16:53 -0700 (PDT) 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 26620-04; Tue, 17 Oct 2006 17:16:52 -0700 (PDT) Received: from [10.1.1.206] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CF3321422CD; Tue, 17 Oct 2006 17:16:50 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85E188BD-3BAE-4316-8C08-36ED31A29660@osafoundation.org> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: AD Evaluation -- extensions Date: Tue, 17 Oct 2006 17:16:44 -0700 To: Eric Scheid X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Yes, absolutely, a way to distinguish extensions-to-the-entry from extensions-for-the-feed would be great, even if there's a possibility that the server would reject one or both. I hadn't even considered that, must have missed that discussion. Client-to-client extensions (metadata or markup that the server can safely ignore and pass through from author to feed consumer) seem very likely and useful in Atom, even more so than in other applications I've compared to (calendaring, file sharing, email). I guess I can turn the flexibility argument around: imagine if Web servers in 1995 rejected, just refused to store, anything that wasn't defined in HTML 3.0; the Web never would have been as flexible as it is today. Of course we can't require Web servers or Atom servers to absolutely accept all content, but we can make it clear what the expectation is and perhaps even offer safe ways of violating the expectation. Lisa On Oct 17, 2006, at 4:31 PM, Eric Scheid wrote: > > On 18/10/06 8:07 AM, "Lisa Dusseault" wrote: > >> Extensions >> >> When the client puts extension elements in a MER, MUST the server >> store those >> unrecognized extension elements? I think the answer to this is >> actually that >> servers often do not and should not be required to do so. That >> makes it hard >> for clients to extend AtomPub's syntax in ways that other clients >> will >> understand but servers don't care about. Consider the >> consequences: when some >> enterprising client developer decides to do something cool and >> useful and >> encounters servers that don't store their metadata in the obvious >> place, the >> client developer is going to quickly work around that by storing >> in some >> unobvious place. For example in HTML comments in the atom entry >> content, or >> microformats, etc. Is that all cool? > > This issue also has implications on what extensions are passed > through to > the published feed ... a client might insert some extension > metadata they > want published (eg. geo-coordinates), and a client might insert some > extension metadata they only want visible within the collection > feed (eg. > editor workflow comments) ... with the understanding also that if > the server > actually understands a particular extension it might result in > extensions > being added/modified outside of the bucket (eg. trackbacks="yes" /> resulting in lots of elements being added) > > We did at one time discuss providing a bucket container > specifically for the > latter, with the assumption that extensions outside the bucket are > data > elements meant for publication. Having a bucket container would > make life > simpler for server implementations -- just store everything as an > xml blob, > the same as they do for atom:content[@type=xhtml]. > > Lisa, would that help? > > e. > > From owner-atom-syntax@mail.imc.org Tue Oct 17 20:35:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzOm-0001OS-99 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:35:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzOk-0005Dj-TJ for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:35:08 -0400 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 k9I0Gk9I056395; Tue, 17 Oct 2006 17:16: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 k9I0Gk8w056394; Tue, 17 Oct 2006 17:16: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.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I0GiNY056387 for ; Tue, 17 Oct 2006 17:16:45 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so94413wxc for ; Tue, 17 Oct 2006 17:16:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RNINsvnnqbZ3oNeF2Ap2z4GQbWN29DkOZQO51qDDD9xN4n0dpEeH5OuImSaCtSDDkIXGATqHudhmbjfUZ23ulOrObCt1d33hXIgjMksgljdpmJs55Cv8a1dbTgwuV94tlS5euRbcKHJoP6ZBaQuE4iIffATed0OiwmrXoGESOZs= Received: by 10.70.117.3 with SMTP id p3mr14788738wxc; Tue, 17 Oct 2006 17:16:44 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 5sm399139wrh.2006.10.17.17.16.43; Tue, 17 Oct 2006 17:16:44 -0700 (PDT) Message-ID: <45357267.4000201@gmail.com> Date: Tue, 17 Oct 2006 17:16:39 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org Subject: Re: [atom-syntax] Atom bidi References: <4534F37E.4000904@gmail.com> <45352FDE.7020709@gmail.com> <45356BC6.5060005@gmail.com> In-Reply-To: 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: bb8f917bb6b8da28fc948aeffb74aa17 Yeah, for now I'm going to keep this bidi code off in an out of the way corner in the Abdera CVS until there's any more movement. Now that I've addressed a short term need I've had on my list for a while, I'll be holding off at least a few weeks to see what Sayre comes up with before deciding whether to update the I-D and I'll hold off making any further updates to Abdera until after the WG makes a clear decision. - James James Holderness wrote: > > Well I'm glad somebody pointed it out because I certainly missed it. > Anyway, for now I'm just checking for an unprefixed dir attribute. If > and when RFC 4287 is ever updated I'll ammend my code accordingly. > > Regards > James > > James M Snell wrote: >> I know there's no such thing :-)... which is precisely why the code I >> implemented is temporary and experimental :-). >> >> - James >> >> Anne van Kesteren wrote: >>> On Tue, 17 Oct 2006 21:32:46 +0200, James M Snell >>> wrote: >>>> 2. Look for the xhtml:dir attribute >>> >>> There's no such thing. (Except perhaps with this new XHTML >>> Modularization madness, but that's best ignored.) > > From owner-atom-syntax@mail.imc.org Tue Oct 17 20:37:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzQu-0006wR-Mo for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:37:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzQp-0005Jx-V2 for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:37:20 -0400 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 k9I0IlR7056517; Tue, 17 Oct 2006 17:18: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 k9I0Ile7056516; Tue, 17 Oct 2006 17:18: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 k9I0Ikch056503; Tue, 17 Oct 2006 17:18:46 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (unknown [207.126.230.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2532C51A1F; Tue, 17 Oct 2006 20:18:45 -0400 (EDT) In-Reply-To: <45356A03.7060601@gmail.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F59DFDD-9E72-43AF-9499-40D75D3740CF@mnot.net> Cc: Lisa Dusseault , atom-protocol Protocol , atom-syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Tue, 17 Oct 2006 17:18:11 -0700 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 I also noticed the split that Lisa mentions when reviewing the draft. I agree that they're not always separate, but it should be pointed out that they can be separate. I didn't see any mechanism to discover what the URI of the "normal" feed is, beyond a link/@rel=alternate in the collection feed; did I miss something? If that's the way to do it, it would be good to call it out (it might be preferable to have a separate link relation, as the semantic isn't just "alternate", but "public", etc.). It might also be good to have something that allows distinguishing between the two (without forcing it) in the service document. Cheers, On 2006/10/17, at 4:40 PM, James M Snell wrote: > My assumption: The separation between "subscription feeds" and > "collection feeds" is not always clear. There are at least two > deployed > implementations I am aware of that use the same feeds for both and I'm > currently working on a third. In Google's new Blogger Beta, for > instance, the subscription feed is also the collection feed. > > I believe that any assumption that the subscription and collections > feeds will always be different is incorrect and dangerous. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Oct 17 20:44:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzXs-0003oQ-LT for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:44:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzXo-0005c2-7e for atompub-archive@lists.ietf.org; Tue, 17 Oct 2006 20:44:32 -0400 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 k9I0QNVx056974; Tue, 17 Oct 2006 17:26: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 k9I0QNQM056973; Tue, 17 Oct 2006 17:26: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I0QLuY056966 for ; Tue, 17 Oct 2006 17:26:22 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so96719wxc for ; Tue, 17 Oct 2006 17:26:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Yvr3shbqramdGWOQcO8DyjQhWJwmAnGt4L2Q1aC8uBSykjFPkTf0N58sOq46/o1qgc7kgZkgifu4MDzdzXWQtntF/rrvC/M6Nq1XweKIFOAtYC6S1B3srp1WxSqQem9yONw2s2xh4GC19KILxmPMxhEXDS/DqvD/6Y0dzqa9mYw= Received: by 10.90.79.6 with SMTP id c6mr5656004agb; Tue, 17 Oct 2006 17:26:21 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 45sm407802wri.2006.10.17.17.26.16; Tue, 17 Oct 2006 17:26:20 -0700 (PDT) Message-ID: <453574A5.7030108@gmail.com> Date: Tue, 17 Oct 2006 17:26:13 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Mark Nottingham CC: Lisa Dusseault , atom-protocol Protocol , atom-syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> <6F59DFDD-9E72-43AF-9499-40D75D3740CF@mnot.net> In-Reply-To: <6F59DFDD-9E72-43AF-9499-40D75D3740CF@mnot.net> 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: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Given that folks are already accustomed to using alternate links to discover subscription feeds, I think it would be reasonable for us to include some statement that within a collection feed, an alternate link with a type of "application/atom+xml" SHOULD be used to point to the public representation of a feed. e.g., ... tag:example.org,2006:foo ... This would go nicely with the use of the alternate link in member entries to point to the public representation of the entry. As Tim suggested, using the alternate link in the service doc would be appropriate. My Workspace ... ... I'd suspect that a lot of existing feed auto-discovery code could be adapted to support this without much difficulty. - James Mark Nottingham wrote: > I also noticed the split that Lisa mentions when reviewing the draft. > > I agree that they're not always separate, but it should be pointed out > that they can be separate. I didn't see any mechanism to discover what > the URI of the "normal" feed is, beyond a link/@rel=alternate in the > collection feed; did I miss something? > > If that's the way to do it, it would be good to call it out (it might be > preferable to have a separate link relation, as the semantic isn't just > "alternate", but "public", etc.). It might also be good to have > something that allows distinguishing between the two (without forcing > it) in the service document. > > Cheers, > > > On 2006/10/17, at 4:40 PM, James M Snell wrote: > >> My assumption: The separation between "subscription feeds" and >> "collection feeds" is not always clear. There are at least two deployed >> implementations I am aware of that use the same feeds for both and I'm >> currently working on a third. In Google's new Blogger Beta, for >> instance, the subscription feed is also the collection feed. >> >> I believe that any assumption that the subscription and collections >> feeds will always be different is incorrect and dangerous. > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Wed Oct 18 04:28:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6mz-0006sM-Mo for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 04:28:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6mu-0007XG-SF for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 04:28:37 -0400 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 k9I84x3d092183; Wed, 18 Oct 2006 01:04: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 k9I84x7E092182; Wed, 18 Oct 2006 01:04: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 mail1.webfaction.com (mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I84vfH092171; Wed, 18 Oct 2006 01:04:58 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.136.207] ([194.221.10.207]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k9I84j96007740; Wed, 18 Oct 2006 03:04:52 -0500 Message-ID: <4535E018.3060909@defuze.org> Date: Wed, 18 Oct 2006 09:04:40 +0100 From: Sylvain Hellegouarch User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: James M Snell CC: Lisa Dusseault , atom-protocol Protocol , atom-syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> In-Reply-To: <45356A03.7060601@gmail.com> X-Enigmail-Version: 0.94.0.0 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: 1.1 (+) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 > My assumption: a client cannot create a media resource without also > creating a media link entry. When I POST a media resource to a > collection, a media link entry is *always* created. Same here. Lisa what do you mean by creating a media resource manually? If you do not use an APP service to create a media resource then it does not fall into APP to tell how this resource will be accessible. To me it's like it's not even part of the collection. > >> - To an outsider or newcomer -- including me even though I've been >> following discussions closely for a while -- there's a part of the Atom >> model that's subtle but important to understand. Consumers of Atom >> feeds are supposed to look at the regular feed document, whereas >> publishers of Atom feeds are supposed to look at other, different >> resources to see how to edit or create posts. Publishers effectively >> look at a different feed than users do, one with extra metadata (the >> rel="edit" links). It's a different model than that of WebDAV or IMAP, >> because rather than have the client specify which metadata it's >> interested in, the server offers two choices with different addresses. >> I believe it would be useful to cover that part of the model upfront in >> addition to the other useful stuff already there. >> > > My assumption: The separation between "subscription feeds" and > "collection feeds" is not always clear. There are at least two deployed > implementations I am aware of that use the same feeds for both and I'm > currently working on a third. In Google's new Blogger Beta, for > instance, the subscription feed is also the collection feed. I would rather have distinct feed for both always but ultimately it's still just an atom feed. Atom rules apply the same way in both cases. I fail to find a case where it can be a real issue to use the same feed. > > I believe that any assumption that the subscription and collections > feeds will always be different is incorrect and dangerous. > >> *Creating resources* >> >> Explicit result of POST, section 4. >> >> Are there zero, one or more resources created with a POST? There's a >> line at the top of section 4 which says that "POST is used to create a >> new, dynamically-named, resource". However, that implies ONE, whereas >> with media entries, a POST could create TWO resources. I believe a >> successful POST request as described here MUST either result in one or >> two resources, never zero, and never 3 or more (in the absence of >> extensions). Section 9.5 says: A client can POST a media type other than application/atom+xml to a Collection. Such a request creates two new resources - one that corresponds to the entity sent in the request, called the Media Resource, and an associated Member Entry, called the Media Link Entry. I find that quite clear at least regarding media resource. > >> What is the expected behavior of seeing a POST to an entry URL (rather >> than a collection URL)? I see that this is currently undefined; it may >> be worth stating that to warn clients. (I'm pretty indifferent on this >> one, as in this case I can't see any obvious harm in different server >> behaviors existing, if un-warned clients try it intentionally without >> knowing the results. The only possible harm is if clients got confused, >> did a POST to an entry URL when a collection URL was intended, and the >> server does a success response which creates new resources or modifies >> existing resources in a way the client did not expect. An error >> response would certainly be harmless for this undefined case but a >> success response could be real interesting.) I would say a server not sending a 405 or any other 40x is broken in that case. > >> Creating entries with multiple media resources >> >> It's never explained how a client would go about creating a feed entry >> with a number of media resources. I imagine that it could be iterative; >> a client could create any of the resources at any time, and at any time >> after creating the feed entry, use PUT to update the feed entry to link >> to new media resources. I assume -- though I didn't see it stated in >> the document -- that it's the client's responsibility in almost all >> cases to put links in the feed entry to point to the media resources, >> otherwise the media resources are unlinked (effectively hidden to >> readers). >> > > My assumption: The relationship between a media link entry and a media > resource is always 1-to-1. If I want an entry to point to multiple > media resources, then I would create one media link entry for each media > resource, then create a separate entry that points to each of the > individually created media resources. > > e.g., > > entry1 --> pic1 > entry2 --> pic2 > entry3 --> pic3 > entry4 --> pic1 > --> pic2 > --> pic3 > > Entries 1, 2 and 3 will always point to their respective media resources > (using atom:content/@src). +1 > >> The exception to this general process is if the client first uses POST >> to create both the media resource and the "Media Link Entry" in one go. >> In this case, can the "Media Link Entry" (MLE) be transformed to a >> regular "Member Entry Resource" (MER)? I thought it would be possible, >> but discussed just a bit with Tim today and he says no, so there you >> have two different readings of the spec. I guess a related question is >> what would happen if a client does a PUT of media content to an entry >> resource, or entry content to a media resource. >> > > My assumption: I had originally wanted the ability to change "MLE" into > a "MER" but the general consensus of the WG seemed to be leading in the > other direction. Once a media link entry is created, it cannot be > changed into some other kind of thing. I personally think that's bogus, > but... > > Regarding what would happen if a client does attempt to change the type > of resource, that's undefined. In my current implementation, the new > content would be silently discarded, which is bogus. I'll likely change > the behavior so that the request is rejected. I think we had that discussion a few weeks ago and it had been agreed that a PUT could change the type of the MLE. I do hope the WG will draw a clear line on that matter because I won't have the possibility to chit-chat with Tim myself to know about it... > >> It's not clear to me whether a linked media entry is always listed in >> the metadata or not. > > My assumption: Yes Same here. > >> - When one or more "edit-media" link relations appear, who has been >> responsible for putting them there? > > My assumption: the Server APP should maybe rule out that if a 'edita-media' appears there can only be one. > >> - When a media resource is deleted, who is responsible for removing the >> media resource link from the MLE? > > My assumption: the Server. When the media resource is deleted, the > associated MLE SHOULD also be deleted. Agreed however... it would be nice if section 9.4 could explain it that way. Currently it only mentions the deletion of the MLE itself resulting in the deletion of the media resource. >> Can a client modify an entry to contain a link relation element in the >> following cases: >> - To result in an "edit" or "edit-media" link relation, where the >> resource represented does not meet the requirements in section 11.1 or 11.2? >> - To result in an "edit" link relation that actually points to a media >> resource, or a "edit-media" link relation that actually points to a MER? > > My assumption: the server is responsible for adding the edit and > edit-media links. Clients are not allowed to modify these values. Agreed. Servers should silently disregard modification to those links. > >> - To point to a resource on a different server entirely? >> - To point to a valid media resource or MER that happen to be in a >> different collection than the one normally used for this feed? >> - Will some servers forbid adding a link relation element entirely? Is >> it important for the client to know that that will always be forbidden >> for that server -- can it detect the "always forbidden" case separately >> from the "this particular edit is forbidden" case? > > My assumption: the decision is ultimately up to individual server > implementations, but in general clients should be allowed to add/edit > all link relations other than the edit and edit-media links. It is > unlikely, however, that your typical blog implementation of APP would > allow a client to modify the alternate link relation. Agreed. > >> Multiple formats/langs for media resources >> >> Multiple formats are not sufficiently defined -- e.g. JPG and PNG >> versions of an image resource. Format negotiation is hard. I found >> guidance for how to select among different "edit-media" link relations >> depending on format and language, but I found no guidance on how to >> create multiple versions. If there's no guidance to clients or servers >> how to do it (would the client create multiple resources in different >> formats? > > Yes. > >> could the server automatically do it as variants? > > Yes. > >> could the server automatically do it as multiple resources, and would > all formats >> be therefore listed?), > > Yes. > >> it's probably worth considering whether there's >> possible interoperability harm here. > > The behavior is ultimately up to the server. No normative behavior > should be specified (largely because we're not yet sure what all folks > will actually want to do). Much agreed with James again. > > My assumption: IMHO, this recommendation no longer unnecessary given > that our recent decision to require that the Location header always > point to the Edit URI of the resource created. I'd prefer that it be > removed. Agreed with James. > > My assumption: If a client DELETE's a MLE, it's associated media > resource SHOULD be deleted. If the client DELETE's the media resource, > the MLE SHOULD be deleted. If the client DELETE's an entry that links > to a media resource in any other way (e.g. there is some other kind of > link relation or an img tag in html content, etc) then the "correct" > behavior is up to the server. Agreed. > >> Can collections be DELETEd? It's fine for servers to allow or no, but >> if servers don't support, what error to use. >> > > My assumption: It's up to the server. 405 Method Not Allowed. Indeed. After all APP is based on HTTP so let's use HTTP error codes. > >> *Editing resources* >> >> Overall, the process for editing a resource is not entirely clear. I >> find the description of creating a resource (POST), and what the server >> can accept, ignore or reject, more clear than the description of editing >> a resource (PUT) . For example, there's normative text in section 9.2.1 >> (an example) relative to creating resources and handling metadata, but >> that text isn't duplicated for editing resources or obviously apply to >> editing resources. Thus: >> - Can the client change the category? (probably yes; MUST the server >> allow?) > > Generally Yes. It's up to the server. I would say yes as well. I think there are only a very limited set of elements client MUST NOT be allowed to edit: id, edit and edit-media links, content, published, update, edited. IMO the rest should be safe for modification. > > In my impl, the server will always report all of the operations that can > be applied to a resource, regardless of whether the current user is > allowed to use those methods. A collection, for instance, will always > specify (at a minimum) the GET and POST methods. An Edit URI will > always specify (at a minimum) the GET, PUT and DELETE methods. Same in my implementation - Sylvain From owner-atom-syntax@mail.imc.org Wed Oct 18 04:47:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga75J-00025Y-NI for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 04:47:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga75I-0000wv-CT for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 04:47:33 -0400 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 k9I8TxnS094847; Wed, 18 Oct 2006 01:29: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 k9I8TxPq094846; Wed, 18 Oct 2006 01:29: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 smtpout.mac.com (smtpout.mac.com [17.250.248.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I8TvvH094836 for ; Wed, 18 Oct 2006 01:29:58 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id k9I8Tu4d021967 for ; Wed, 18 Oct 2006 01:29:57 -0700 (PDT) Received: from [10.0.1.2] (d188090.adsl.hansenet.de [80.171.188.90]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k9I8Tqt1013622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 18 Oct 2006 01:29:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Atom-Syntax From: Jan Algermissen Subject: Question on undefinedAttribute/Content Date: Wed, 18 Oct 2006 10:29:50 +0200 X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hi, RFC4287 distinguishes between 'undefined' and 'extension' constructs. I am understanding the distinction to imply that conformant software should provide for handling extension elements, but can and should ignore any occurrences of undefinedAttribute or undefinedContent. Is that understanding correct? Thanks, Jan From owner-atom-syntax@mail.imc.org Wed Oct 18 08:21:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaAQ4-0000uZ-QF for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 08:21:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaAQ2-0003nf-9A for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 08:21:12 -0400 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 k9IBwqF5019609; Wed, 18 Oct 2006 04:58: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 k9IBwqcV019607; Wed, 18 Oct 2006 04:58: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IBwo5t019586; Wed, 18 Oct 2006 04:58:51 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GaA4O-0008Ut-Pk; Wed, 18 Oct 2006 13:58:48 +0200 Received: from ultra13.rbg.informatik.tu-darmstadt.de ([130.83.160.103]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.62 #12) id 1GaA4O-0006Zv-M6; Wed, 18 Oct 2006 13:58:48 +0200 Message-ID: <453616F7.506@rbg.informatik.tu-darmstadt.de> Date: Wed, 18 Oct 2006 13:58:47 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mail/News 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: James M Snell CC: Lisa Dusseault , atom-protocol Protocol , atom-syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> In-Reply-To: <45356A03.7060601@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b James M Snell wrote: > Lisa Dusseault wrote: >> Explicit result of POST, section 4. >> >> Are there zero, one or more resources created with a POST? There's a >> line at the top of section 4 which says that "POST is used to create a >> new, dynamically-named, resource". However, that implies ONE, whereas >> with media entries, a POST could create TWO resources. I believe a >> successful POST request as described here MUST either result in one or >> two resources, never zero, and never 3 or more (in the absence of >> extensions). > > My assumption: A POST could actually create any number of resources. > For instance, when I POST an entry to my weblog, at least two resources > will be created (the editable entry and the HTML "permalink" page) and > several others will be modified (the collection feed, the blog index > page, archive pages, etc). Similarly, when I POST a media resource, I > would expect that multiple resources could be created. How many > resources are created/modified is up to the server implementation. From > the client's point of view, there are only two resources that are of > immediate concern: the atom:entry and the collection feed. At the very > least, A successful POST should result in the creation of the > atom:entry. No other assumptions can be made beyond that. Even the assumption that a successful POST results in the creation of an atom:entry may be false; consider the case of a moderated collection responding with a "202 Accepted". Hence a successful ("2xx" response code) POST can very well end up creating no resources whatsoever. That being said, a successful POST might, on the other hand, create more than two resources as well. As server could, e.g., automatically convert image/gif media resource to image/png, making both available. At least that's the way I see these things. Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Wed Oct 18 10:12:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC9L-0004AG-0H for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:12:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaC9B-0005ly-RA for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:12:02 -0400 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 k9IDmPiW031173; Wed, 18 Oct 2006 06:48: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 k9IDmPkq031167; Wed, 18 Oct 2006 06:48: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9IDmLOa031105 for ; Wed, 18 Oct 2006 06:48:22 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 Oct 2006 13:48:15 -0000 Received: from xdsl-213-196-249-83.netcologne.de (EHLO klangraum) [213.196.249.83] by mail.gmx.net (mp014) with SMTP; 18 Oct 2006 15:48:15 +0200 X-Authenticated: #163624 Date: Wed, 18 Oct 2006 15:48:14 +0200 From: "A. Pagaltzis" To: Atom-Syntax Subject: Re: Question on undefinedAttribute/Content Message-ID: <20061018134814.GL26771@klangraum> Mail-Followup-To: Atom-Syntax References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k9IDmPiW031173 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab * Jan Algermissen [2006-10-18 10:45]: > RFC4287 distinguishes between 'undefined' and 'extension' > constructs. I am understanding the distinction to imply that > conformant software should provide for handling extension > elements, but can and should ignore any occurrences of > undefinedAttribute or undefinedContent. >=20 > Is that understanding correct? Yes. To be precise: Extension constructs are any markup which the software knows to interpret. Undefined markup is anything it doesn=E2=80=99t know to interpret. In particular, this includes any future additions to Atom itself. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Oct 18 10:20:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCHy-0007jq-0v for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:20:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCHs-0007RG-G0 for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:20:58 -0400 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 k9IDuHqM032000; Wed, 18 Oct 2006 06:56: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 k9IDuHL9031997; Wed, 18 Oct 2006 06:56: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IDuFnv031985 for ; Wed, 18 Oct 2006 06:56:16 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 1729 invoked by uid 17064); 18 Oct 2006 13:56:14 -0000 Received: from unknown (HELO [192.168.1.5]) ([62.47.188.50]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Oct 2006 13:56:14 -0000 In-Reply-To: <45356A03.7060601@gmail.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00047E5F-8C63-488D-B26F-BC9349C9D5D0@bblfish.net> Cc: Lisa Dusseault , atom-protocol Protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Wed, 18 Oct 2006 15:56:34 +0200 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On 18 Oct 2006, at 01:40, James M Snell wrote: >> [snip] >> The spec says "The value of atom:updated is only changed when the >> change >> to a member resource is considered significant. " The use of passive >> voice obscures who does what here. When the client doesn't suggest a >> value for "atom:updated", does the server provide one, and if so, how >> does the server know what is "significant"? I thought it would >> always >> be the client suggesting values, but Tim says that the server >> controls >> atom:updated which could imply that the client doesn't even need to >> suggest values. See above about whether the server MUST accept >> certain >> values for "updated", or more likely, MUST NOT accept suggested >> values >> for "updated" when they're clearly wrong (e.g. this entry was last >> updated on October 16, 1906). >> > > My assumption: Tim is correct. The server controls atom:updated. > While > the client is required to provide a valid atom:updated element, the > server can (and in most cases will) ignore that value. Completely disagree. If the server controls atom:updated then what was the point of the whole discussion of app:edited? the client controls app:edited. It is the client who decides what if there was a significant change. The server controls app:edited. Any edit, changes app:edited. If you have it your way, then atom:updated will end up meaning app:edited, which Tim Bray specifically mentioned he did not want in his wiki example. Henry From owner-atom-syntax@mail.imc.org Wed Oct 18 10:53:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCnN-0000aV-O9 for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:53:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCnJ-0004ma-RZ for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:53:25 -0400 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 k9IESQXD035840; Wed, 18 Oct 2006 07:28: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 k9IESQsL035838; Wed, 18 Oct 2006 07:28: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IESP9j035825 for ; Wed, 18 Oct 2006 07:28:25 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 19818 invoked by uid 17064); 18 Oct 2006 14:28:24 -0000 Received: from unknown (HELO [192.168.1.5]) ([62.47.188.50]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Oct 2006 14:28:24 -0000 In-Reply-To: <45356A03.7060601@gmail.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EB78A3E-6E3C-452A-A296-A948E64A1CBD@bblfish.net> Cc: Lisa Dusseault , atom-protocol Protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Wed, 18 Oct 2006 16:28:43 +0200 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Many thanks to Lisa for the lengthy and detailed comments. I am just replying to those comments relating to the parts of the spec I understand best. On 18 Oct 2006, at 01:40, James M Snell wrote: >> *Synchronization* >> >> I predict that some AtomPub authoring clients will attempt to >> synchronize: to maintain an offline copy of the feed including all >> its >> MERs and media resources, and to keep that offline copy up-to-date. >> Some will probably even allow offline authoring of new posts, and >> offer >> to synchronize when the client next goes online -- because of the >> possibility of multiple authors, this may mean at times that the >> client >> would download new entries created by other authors, upload new >> entries >> created offline, and reconcile its offline copy of feed documents. >> >> Because authoring clients will attempt to do this based on Last- >> Modified >> and ETag -- after all, the functionality is all there in some form or >> another -- the spec needs a little more clarity on how the client can >> rely on this working. Otherwise, some servers may omit features that >> these authoring clients require, or implement them oddly. While I >> would >> never suggest repeating all the requirements from other specs (in >> this >> case HTTP), there are cases where clarity and interoperability are >> greatly improved by at least referencing explicitly requirements from >> HTTP. It's also possible to add new requirements based on >> features in >> HTTP, that apply to Atom servers alone. >> > > I would be very happy to see some discussion of this in the spec, > especially if it normatively required the use of ETags for offline > synchronization. I think synchronisation would be best dealt with by adding functionality to sort the collection in different ways. Currently the sort order is a SHOULD on atom:updated. That does not allow clients to find the most recent edits. If there were a way to sort the entries by app:edited one could find the most recent edits quite quickly. Doing a HEAD on all the entries to find out which changed by comparing etags is not really an option. For large blogs such as Tim Bray's ongoing this would use up way to many resources and take way too long. >> [snip] >> of HTTP (calendaring) than the general case. If HTTP >> synchronization in >> authoring cases were clearly defined and had not lead to years of >> arguments since the last HTTP update, I would probably feel >> differently >> about just silently relying on the mechanisms in HTTP. >> > > +1 > >> In any case, I have very specific brief suggestions to cover >> synchronization so that it's implemented more successfully than not. >> - Consider adding a brief section offering clients non-normative >> guidelines on synchronization. It doesn't have to limit server >> behavior >> so much as point out with green and red lights where the fairway is >> (mixing transportation and golfing metaphors in my head) >> - Make a few requirements of servers to avoid some of those HTTP >> ambiguities. For example: >> "The ETag or Last-Modified values for a member resource MUST >> change when >> any metadata in the resource changes, as well as text/content, and >> this >> includes "next" and "last" link relation values. The ETag or >> Last-Modified values of a member resource MUST NOT change solely >> because >> an associated other resource (e.g. the media resource being an >> associated resource to the media link entry resource) changed. " > > +0.5. I would add that the ETag/Last-Modified values of a resource > SHOULD NOT change solely because of non-significant changes to the > infoset serialization of an entry (e.g. a different namespace > prefix is > used, or whitespace is added or removed, etc). I would also prefer > that > the ETag for a MLE change when it's associated media resource is > updated. > >> >> More open questions that might be related to synch or might have >> relevance even for clients that don't do full synch: >> - What is the relationship, if any, between the "atom:updated" >> value and >> the HTTP "Last-Modified" value. Can the "atom:updated" value ever be >> later (greater) than the "Last-Modified" value? I believe it can >> be the >> same or earlier, but the spec doesn't disallow the broken case. > > My assumption: There is no relationship. atom:updated should be > treated > as being entirely independent of Last-Modified. yes. > It might be reasonable, > however, to define a relationship between Last-Modified and > app:edited. No. In discussions on the topic of synchronisation it became obvious that people wanted to have servers add properties to entries, such as changing the number of comments for an entry, without this changing app:edited. A new app:modified would be the closest to something that could have a 1-1 relation to Last-Modified. But there was a lot of push back against app:modified as being too britle - ie. changing too often (xml formating changes could cause app:modified to change) >> - Is it clear whether the client MUST GET the entry after >> modifying it >> in order to have an accurate offline cache? (this was mentioned in a >> post by Broyer Jul 13, but not in the document). I believe this >> is made >> clear already for the cases of getting the feed and also for >> POST/create, but not for PUT/modify. > > My assumption: Yes. > >> - Am I correct that the general assumption is that id's are there >> to see >> what entries are new, and URLs are there to see where to get >> them? That >> may mean that URLs could change, for a given ID -- Perhaps a >> feature to >> change the slug name of a image after attaching it. Is that >> theoretically possible? > > My assumption: Yes. ID's also help to detect changes so that old > entries > are not flagged as new when insignificant updates are made. yes. Id's are there also to be able to find multiple versions of a same document. >> >> There are also efficiency considerations. >> - The spec could require that servers MUST return either the ETag, or >> the Last-Modified value, in any successful POST or PUT response. I >> personally favour this so that clients can rely on it, though >> obviously >> other opinions are valid here. > > I'd prefer this. My current implementation always returns the ETag on > the POST response. I think it is a good idea to return Etags in the header. Well written clients should keep track of them. > >> - I really liked the idea of putting ETag in the author's feed, as >> discussed on the list but not appearing in the document, again for >> efficiency. > > Are you referring to the app:etag element? This is no longer necessary, with app:edited. The client can keep track of etags by keeping the http header info. There is no need to place this in the entry itself. Henry From owner-atom-syntax@mail.imc.org Wed Oct 18 10:59:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCt4-0003dP-Vh for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:59:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCt2-0005uz-JX for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 10:59:18 -0400 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 k9IEYLSJ036375; Wed, 18 Oct 2006 07: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 k9IEYLDa036372; Wed, 18 Oct 2006 07:34: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IEYKQk036360 for ; Wed, 18 Oct 2006 07:34:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t10so270055wxc for ; Wed, 18 Oct 2006 07:34:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=V3vkIl6utT39swGq9UNIbSWdw7zrfoceJKg8OdAarfVXz257vLjqx2hm+n4ObCNehEmgiAK7BBDDOIqFWj4jWqgGJaDbXOT2qkbAl1vloFykbFq9wGLN9/aREEdJgRgS//xzvf+pJ7gk2/sOnZalXNbepqZlTsBjt3lFSfSglLU= Received: by 10.90.72.10 with SMTP id u10mr6297177aga; Wed, 18 Oct 2006 07:34:19 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 38sm1769215wrl.2006.10.18.07.34.18; Wed, 18 Oct 2006 07:34:19 -0700 (PDT) Message-ID: <45363B67.5050204@gmail.com> Date: Wed, 18 Oct 2006 07:34:15 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Henry Story CC: Lisa Dusseault , atom-protocol Protocol , atom-syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> <00047E5F-8C63-488D-B26F-BC9349C9D5D0@bblfish.net> In-Reply-To: <00047E5F-8C63-488D-B26F-BC9349C9D5D0@bblfish.net> 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: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 No, it means only that it's the server's responsibility to determine when atom:updated should be updated and when it shouldn't. If the server wishes to delegate that responsibility to the client, then that's fine. - James Henry Story wrote: > [snip] > Completely disagree. > If the server controls atom:updated then what was the point of the whole > discussion of app:edited? > the client controls app:edited. It is the client who decides what if > there was a significant change. > The server controls app:edited. Any edit, changes app:edited. > > If you have it your way, then atom:updated will end up meaning > app:edited, which Tim Bray specifically mentioned he did not want in his > wiki example. > > Henry > From owner-atom-syntax@mail.imc.org Wed Oct 18 11:03:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCx3-0005ng-Gk for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 11:03:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCx2-0007bt-4v for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 11:03:25 -0400 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 k9IEZ6nA036440; Wed, 18 Oct 2006 07:35: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 k9IEZ6Lj036438; Wed, 18 Oct 2006 07:35: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IEZ52L036426 for ; Wed, 18 Oct 2006 07:35:05 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 23722 invoked by uid 17064); 18 Oct 2006 14:35:05 -0000 Received: from unknown (HELO [192.168.1.5]) ([62.47.188.50]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Oct 2006 14:35:05 -0000 In-Reply-To: <453635B8.1020602@aol.net> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> <00047E5F-8C63-488D-B26F-BC9349C9D5D0@bblfish.net> <453635B8.1020602@aol.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Lisa Dusseault Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Wed, 18 Oct 2006 16:35:25 +0200 To: atom-protocol Protocol , atom-syntax Syntax X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On 18 Oct 2006, at 16:10, John Panzer wrote: >>> >>> My assumption: Tim is correct. The server controls >>> atom:updated. While >>> the client is required to provide a valid atom:updated element, the >>> server can (and in most cases will) ignore that value. >> >> >> Completely disagree. >> If the server controls atom:updated then what was the point of >> the whole discussion of app:edited? >> the client controls app:edited. It is the client who decides what >> if there was a significant change. >> The server controls app:edited. Any edit, changes app:edited. > > I think you have a typo somewhere in the above. Duh. You are right. I wish there were unit tests for typing docs. Why is it one always has to test everything in life? I meant: If the server controls atom:updated then what was the point of the whole discussion of app:edited? The client controls atom:updated. It is the client who decides what a significant change is. The server controls app:edited. Any edit changes app:edited. Henry From owner-atom-syntax@mail.imc.org Wed Oct 18 11:20:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDQ-0004ij-EY for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 11:20:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaD1J-0008Nk-CV for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 11:07:52 -0400 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 k9IElb1F037606; Wed, 18 Oct 2006 07:47: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 k9IElbjv037605; Wed, 18 Oct 2006 07:47: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 nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IEla8d037599 for ; Wed, 18 Oct 2006 07:47:37 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id s1so104321nze for ; Wed, 18 Oct 2006 07:47:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NMYJhby7TsfsXUDZ6Oc9VWktwXe+nzC99sjbJIvBqiGpekEqT+z/aLQhaWDGXG8+GmNFT1tEgE5Wzcrrq4oJXX8c27njTkRfqcYELa2PwlIZlZfo3W4hQVPkO6wJt8MdumEhrz61I9Yrfy6UtvctRu/KueguQVPCRQy9AV0vEMs= Received: by 10.48.210.16 with SMTP id i16mr3832455nfg; Wed, 18 Oct 2006 07:47:19 -0700 (PDT) Received: by 10.49.28.6 with HTTP; Wed, 18 Oct 2006 07:47:19 -0700 (PDT) Message-ID: Date: Wed, 18 Oct 2006 16:47:19 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Question on undefinedAttribute/Content In-Reply-To: <20061018134814.GL26771@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061018134814.GL26771@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 2006/10/18, A. Pagaltzis: > > * Jan Algermissen [2006-10-18 10:45]: > > RFC4287 distinguishes between 'undefined' and 'extension' > > constructs. I am understanding the distinction to imply that > > conformant software should provide for handling extension > > elements, but can and should ignore any occurrences of > > undefinedAttribute or undefinedContent. > > > > Is that understanding correct? > > Yes. To be precise: > > Extension constructs are any markup which the software knows to > interpret. > > Undefined markup is anything it doesn't know to interpret. In > particular, this includes any future additions to Atom itself. Nope! Extension is what's covered by section 6.4, child elements of atom:entry, atom:feed, atom:source and Person constructs. Undefined markup is every other markup not defined by the spec: attributes on any atom:* element, and child elements and text inside other elements (atom:category, atom:link, etc.) Whether the application knows what to do with markup, it's still extension markup (e.g. thr:in-reply-to) or undefined markup (e.g. thr:replies-count). -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Oct 18 11:21:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDEv-0006Sv-M6 for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 11:21:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDEt-0002xh-D6 for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 11:21:53 -0400 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 k9IEkBo7037473; Wed, 18 Oct 2006 07:46: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 k9IEkBar037471; Wed, 18 Oct 2006 07:46: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IEk9MW037455 for ; Wed, 18 Oct 2006 07:46:10 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 29667 invoked by uid 17064); 18 Oct 2006 14:46:09 -0000 Received: from unknown (HELO [192.168.1.5]) ([62.47.188.50]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 Oct 2006 14:46:09 -0000 In-Reply-To: <45363B67.5050204@gmail.com> References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> <00047E5F-8C63-488D-B26F-BC9349C9D5D0@bblfish.net> <45363B67.5050204@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D584015-BD9E-4C2A-B38A-01E223C55B1F@bblfish.net> Cc: Lisa Dusseault , atom-protocol Protocol , atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 Date: Wed, 18 Oct 2006 16:46:29 +0200 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On 18 Oct 2006, at 16:34, James M Snell wrote: > No, it means only that it's the server's responsibility to determine > when atom:updated should be updated and when it shouldn't. If the > server wishes to delegate that responsibility to the client, then > that's > fine. Is this not splitting hairs a little? In the end it is always the server who is going to decide if it wants to accept anything at all. The server could also change the content if it wished (though I would not use such a service, having lived through the greed of the .com, we can be assured that servers will want to add their adds to your content). If we use the word responsibility this way then it's not going to help us distinguish anything interesting. When it comes down to it, my feeling was that the client decides whether or not it wants to check that box "significant update" or not. The client does not have any say in what the value of app:edited is. But special cases can be made. It's just that those would be understood to be deviations from the norm. > - James > > Henry Story meant to write: >> [snip] >> If the server controls atom:updated then what was the point of >> the whole discussion of app:edited? >> The client controls atom:updated. It is the client who decides >> what a significant change is. >> >> The server controls app:edited. Any edit changes app:edited. From owner-atom-syntax@mail.imc.org Wed Oct 18 15:10:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGng-0002T2-Ig for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 15:10:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaGne-00087f-5i for atompub-archive@lists.ietf.org; Wed, 18 Oct 2006 15:10:00 -0400 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 k9IIjeNJ058941; Wed, 18 Oct 2006 11:45: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 k9IIjens058940; Wed, 18 Oct 2006 11:45: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 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 k9IIjd9O058931 for ; Wed, 18 Oct 2006 11:45:39 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id s7so413434wxc for ; Wed, 18 Oct 2006 11:45:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gzPDAUfTkNKDs1lC55si8xO7RAHVo33WiVRnq3vqvTyfDj4mgJCOFDb1WO7gXt4WiGM3lehA2cLLOeaGfvRkrnUs7DK54QoyVPSY02C0In5RK8bExhwxiuoaQGXrHZw6muvXnxaYojudw1o/GlMU8e0jygJrMcyxUJtn4f9BNbg= Received: by 10.90.27.6 with SMTP id a6mr6754934aga; Wed, 18 Oct 2006 11:45:36 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm2355929wrl.2006.10.18.11.45.35; Wed, 18 Oct 2006 11:45:36 -0700 (PDT) Message-ID: <4536764C.6010207@gmail.com> Date: Wed, 18 Oct 2006 11:45:32 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Henry Story CC: Lisa Dusseault , atom-protocol Protocol , atom-syntax Subject: Re: AD Evaluation of draft-ietf-atompub-protocol-11 References: <8BD53B7C-5B43-4F2D-8DC5-0281CCB84B84@commerce.net> <45356A03.7060601@gmail.com> <00047E5F-8C63-488D-B26F-BC9349C9D5D0@bblfish.net> <45363B67.5050204@gmail.com> <7D584015-BD9E-4C2A-B38A-01E223C55B1F@bblfish.net> In-Reply-To: <7D584015-BD9E-4C2A-B38A-01E223C55B1F@bblfish.net> 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: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c I think it is important in order to make the distinction between whether the server MUST, SHOULD or MAY accept the atom:updated value provided by the client. I would argue that it needs to be a MAY with a clear statement that allowing the client to set the value is quite likely going to be very useful. The bottom line for me is that I do not yet believe we have enough of an understanding how folks are going to be using the protocol. Stir in too many MUSTs and SHOULDs and you end up needlessly restricting what folks can do. If a best practice emerges later and it becomes clear that allowing the client to set the atom:update value is an Absolute Good, then I'll be all for coming with the a BCP documenting that fact. - James Henry Story wrote: > On 18 Oct 2006, at 16:34, James M Snell wrote: >> No, it means only that it's the server's responsibility to determine >> when atom:updated should be updated and when it shouldn't. If the >> server wishes to delegate that responsibility to the client, then that's >> fine. > > Is this not splitting hairs a little? In the end it is always the server > who is going to decide if it wants to accept anything at all. The server > could also change the content if it wished (though I would not use such > a service, having lived through the greed of the .com, we can be assured > that servers will want to add their adds to your content). If we use the > word responsibility this way then it's not going to help us distinguish > anything interesting. > > When it comes down to it, my feeling was that the client decides whether > or not it wants to check that box "significant update" or not. The > client does not have any say in what the value of app:edited is. > > But special cases can be made. It's just that those would be understood > to be deviations from the norm. > >> - James >> >> Henry Story meant to write: >>> [snip] >>> If the server controls atom:updated then what was the point of the >>> whole discussion of app:edited? >>> The client controls atom:updated. It is the client who decides what a >>> significant change is. >>> >>> The server controls app:edited. Any edit changes app:edited. > > From owner-atom-syntax@mail.imc.org Mon Oct 23 19:44:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9TA-0000oI-0C for atompub-archive@lists.ietf.org; Mon, 23 Oct 2006 19:44:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc9T7-0004uV-OU for atompub-archive@lists.ietf.org; Mon, 23 Oct 2006 19:44:35 -0400 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 k9NN7YUY072328; Mon, 23 Oct 2006 16:07: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 k9NN7Yqp072327; Mon, 23 Oct 2006 16:07: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 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 k9NN7WMJ072313 for ; Mon, 23 Oct 2006 16:07:33 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (unknown [207.126.230.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 740F5519EB; Mon, 23 Oct 2006 19:07:31 -0400 (EDT) In-Reply-To: <452E0DFD.6010204@rbg.informatik.tu-darmstadt.de> References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> <452E0DFD.6010204@rbg.informatik.tu-darmstadt.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Mon, 23 Oct 2006 16:07:29 -0700 To: Andreas Sewe X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 OK. I'm adding this text just after the list of feed types in the introduction; ---8<--- The semantics of a feed that combines these types is undefined by this specification. --->8--- WRT what future specs can or can't do, that's pretty much up to them. Cheers, On 2006/10/12, at 2:42 AM, Andreas Sewe wrote: > Mark Nottingham wrote: >> Andreas Sewe wrote: >>> But it would be desirable, IMHO, to be able to link to archived, >>> older versions of a complete feed from within the current >>> complete feed document. >>> >>> Say, a feed document contains this month's Top Ten. Wouldn't it >>> be nice if the feed document could link to September's Top Ten, >>> in case anybody is interested in all the recent Top Ten lists? >>> And linking to archived feed documents is precisely what "prev- >>> archive" and "next-archive" are for. So why can't I use them in >>> conjunction with complete feeds? >> I think you're trying to reconstruct a different dimension; >> archived feeds, when reconstructed, contain only entries that are >> currently considered members of the feed; what you want to do is >> to have snapshots of the feed's members over time, separate from >> what the current members are. > > Right. The point is that for non-complete feeds members are only > ever added (never removed) as time goes by. Hence you can > reconstruct a previous revision of an Archived Feed simply by > following the "prev-archive" links far enough into the past; so > there is, for non-complete Archived Feeds, no real need for another > link relation to cover this dimension: > >> This might work as a "prev-version" link relation... > > Now there are already "previous" and "prev-archive"; do we really > need "prev-version" to cover the case of Complete Feeds? At least > for non-complete Archived Feeds it is not really needed, which > gives me the gut feeling that "prev-version" might not be needed > for Complete Feeds either. (Unfortunately, I cannot come up with a > satisfactory definition for "prev-archive" that would work for both > cases, complete and non-complete. But that does not mean there is > none...) > > (For the moment, the "related" link relation with an explanatory > @title will do.) > >>> I am aware, now, that this is not what the current draft says, >>> since the three types of feed (complete, paged, and archived >>> feed) can't be combined in *any* way, even though the draft's >>> introduction claims that "[t]hese types are complementary". But >>> at least some of the additional expressiveness offered by the >>> combination of complete with either paged or archive feeds would >>> be nice to have -- even though it adds some minor complexities. >> My gut feeling is that while there might be some use cases for >> this sort of thing, it's going beyond the 80/20 point, and adding >> a lot of complexity/abstraction. When I said that they were >> complementary, I meant that together, they cover most feeds in >> common use today, not that they can be used together. > > I see. Maybe it would be a good idea to spell this out explicitly > in the spec, even if the "Completeness is defined as having all of > the entries in one physical document" condition implies it. That > way you can be sure that everyone, me included, gets the semantics > right. (FWIW, nothing prevents stable logical feeds from being both > Archived and Paged Feeds, right? Only unstable feeds can just be > Paged, not Archived.) > >> I do want to address the combination issue, however. I'm inclined >> to just state that the semantics of feeds that have more than one >> type is undefined by this spec. Does that work for you? > > It does. It would be worthwhile, however, to state that a future > revision of your spec might choose to define behavior for these > cases. (None of the features I have proposed would contradict the > current semantics of Complete, Paged, and Archived Feeds.) > > Regards, > > Andreas Sewe -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Oct 23 19:58:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9gO-0004SE-VO for atompub-archive@lists.ietf.org; Mon, 23 Oct 2006 19:58:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc9gJ-0008N1-J2 for atompub-archive@lists.ietf.org; Mon, 23 Oct 2006 19:58:16 -0400 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 k9NNgSO2076470; Mon, 23 Oct 2006 16:42: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 k9NNgSHB076469; Mon, 23 Oct 2006 16:42: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NNgPif076459 for ; Mon, 23 Oct 2006 16:42:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id t12so929225wxc for ; Mon, 23 Oct 2006 16:42:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bMGSAzO4rjr89oUZ0iUd1Y5OIV6r2FJXxyIp4U0FHDFetYu6OgCiKiuOOVGIAsVhEbJhf4qb8TGxwEQto4EW3JDhwQVkQTE/U4ogm3Tu1HGzWgmOgOWLwPhHsh16zSPtp0X3HTtLb+QcRd5fJ6E0J45gM1ew6BCrE0Yp4zyQgEQ= Received: by 10.90.78.9 with SMTP id a9mr2823483agb; Mon, 23 Oct 2006 16:42:25 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 15sm392533wrl.2006.10.23.16.42.24; Mon, 23 Oct 2006 16:42:25 -0700 (PDT) Message-ID: <453D5357.2000901@gmail.com> Date: Mon, 23 Oct 2006 16:42:15 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Mark Nottingham CC: Andreas Sewe , Atom Syntax Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> <452E0DFD.6010204@rbg.informatik.tu-darmstadt.de> In-Reply-To: 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: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Mixing things can definitely get a bit wierd. For instance, if I structure my archive feeds to show all entries within a given month rather than by a certain number of entries, each individual feed is both complete and part of a larger set. Complete in the sense that each represents a complete set within a limited window of time. tag:example.org,2006:archives/200609.xml" /> ... - James Mark Nottingham wrote: > > OK. I'm adding this text just after the list of feed types in the > introduction; > > ---8<--- > The semantics of a feed that combines these types is undefined by this > specification. > --->8--- > > WRT what future specs can or can't do, that's pretty much up to them. > > Cheers, > > [snip] From owner-atom-syntax@mail.imc.org Mon Oct 23 20:14:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9vv-0005UV-V5 for atompub-archive@lists.ietf.org; Mon, 23 Oct 2006 20:14:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc9vs-00035l-Gi for atompub-archive@lists.ietf.org; Mon, 23 Oct 2006 20:14:19 -0400 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 k9NNsaEl077701; Mon, 23 Oct 2006 16: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 k9NNsake077700; Mon, 23 Oct 2006 16: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 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 k9NNsZKN077694 for ; Mon, 23 Oct 2006 16:54:36 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (unknown [207.126.230.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 411F45194B; Mon, 23 Oct 2006 19:54:35 -0400 (EDT) In-Reply-To: <453D5357.2000901@gmail.com> References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> <452E0DFD.6010204@rbg.informatik.tu-darmstadt.de> <453D5357.2000901@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Andreas Sewe , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Mon, 23 Oct 2006 16:54:33 -0700 To: James M Snell X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Yep. Every feed is, in some sense, complete. And, every feed document is potentially part of more than one logical feed. Many of the use cases take their cues from the surrounding context / use case; below you're basically saying: * If you're subscribing to this URI, you've got the whole thing (and BTW, it shouldn't change, because it's an archive). * If you're putting together an archived feed, and this is one step in that, the previous archive is over there. On 2006/10/23, at 4:42 PM, James M Snell wrote: > Mixing things can definitely get a bit wierd. For instance, if I > structure my archive feeds to show all entries within a given month > rather than by a certain number of entries, each individual feed is > both > complete and part of a larger set. Complete in the sense that each > represents a complete set within a limited window of time. > > > tag:example.org,2006:archives/200609.xml" /> > > > > > ... > > > - James > > Mark Nottingham wrote: >> >> OK. I'm adding this text just after the list of feed types in the >> introduction; >> >> ---8<--- >> The semantics of a feed that combines these types is undefined by >> this >> specification. >> --->8--- >> >> WRT what future specs can or can't do, that's pretty much up to them. >> >> Cheers, >> >> [snip] -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Oct 24 05:00:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcI90-0000E3-NE for atompub-archive@lists.ietf.org; Tue, 24 Oct 2006 05:00:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcHyQ-00070Q-Cl for atompub-archive@lists.ietf.org; Tue, 24 Oct 2006 04:49:28 -0400 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 k9O8NswE070736; Tue, 24 Oct 2006 01:23: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 k9O8Ns78070735; Tue, 24 Oct 2006 01:23: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 joe.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9O8Nqt3070727 for ; Tue, 24 Oct 2006 01:23:53 -0700 (MST) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.6] (fat-tony.greenbytes.de [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 0515156DC4; Tue, 24 Oct 2006 10:23:49 +0200 (CEST) In-Reply-To: References: <452A682E.4000509@rbg.informatik.tu-darmstadt.de> <452BA4F9.7050305@rbg.informatik.tu-darmstadt.de> <48DFAB37-DE02-4211-913C-5DE986A53C4B@mnot.net> <452E0DFD.6010204@rbg.informatik.tu-darmstadt.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <730AEF2B-66D7-4D7B-A4E4-7445CB1B2660@greenbytes.de> Cc: Andreas Sewe , Atom Syntax Content-Transfer-Encoding: 7bit From: Stefan Eissing Subject: Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07 Date: Tue, 24 Oct 2006 10:23:31 +0200 To: Mark Nottingham 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: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Am 24.10.2006 um 01:07 schrieb Mark Nottingham: > > OK. I'm adding this text just after the list of feed types in the > introduction; > > ---8<--- > The semantics of a feed that combines these types is undefined by > this specification. > --->8--- > > WRT what future specs can or can't do, that's pretty much up to them. +1. //Stefan From owner-atom-syntax@mail.imc.org Thu Oct 26 12:51:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Rt-0000Xh-Ph for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 12:51:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Rk-0006Tl-7D for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 12:51:21 -0400 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 k9QGOECO055808; Thu, 26 Oct 2006 09:24: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 k9QGOERq055807; Thu, 26 Oct 2006 09:24: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 mclniron02-ext.bah.com (mclniron02-ext.bah.com [156.80.1.73]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QGOAF4055789 for ; Thu, 26 Oct 2006 09:24:13 -0700 (MST) (envelope-from gopalan_sri@bah.com) Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron02-ext.bah.com with ESMTP; 26 Oct 2006 12:24:11 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: i="4.09,362,1157342400"; d="scan'208"; a="79012256:sNHT17414588" Received: from MCLNEXVS01.resource.ds.bah.com ([156.80.7.104]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:24:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Adding POST capability to atom:link Date: Thu, 26 Oct 2006 12:24:09 -0400 Message-ID: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adding POST capability to atom:link Thread-Index: Acb5HAz90+NFTSF5QIK/Vu3FcHJatA== From: "Gopalan Sri" To: X-OriginalArrivalTime: 26 Oct 2006 16:24:09.0941 (UTC) FILETIME=[2A84B050:01C6F91B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9QGODF4055802 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, I am trying to use opensearch to do some paging of my search results and I have a question regard adding POST capabilities to the atom:link construct. The information I want to pass back to the server is complex in nature and makes sense to capture in XML. My question is whether or not there are any thoughts or plans to extend the atom:link contruct to support something like this: Thanks. Sri Gopalan Booz Allen Hamilton Office: Allen 147 Tel: 703.377.1404 Mobile: 703.395.4057 From owner-atom-syntax@mail.imc.org Thu Oct 26 13:09:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8jH-00034O-Re for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 13:09:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8jF-0000tx-FX for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 13:09:19 -0400 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 k9QGq9pe061859; Thu, 26 Oct 2006 09:52: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 k9QGq9FT061858; Thu, 26 Oct 2006 09:52: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QGq7YM061844 for ; Thu, 26 Oct 2006 09:52:08 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so1052948nfa for ; Thu, 26 Oct 2006 09:52:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hvIqEtdts8MRkii/NoiQri7d2DEGiv1q+xocg8+O7NMwiGfmS6Hg4nuBNz9EWaguVMXZcZzItlhVKjoe5mFj+9TuCrhvVeNR52Rft8XBOMKP6C6uq9J+q1M59k86mZFjUV2fFrLUAED35J6GDtulbrOTgpcQoQYOrdvjTL3Uqgw= Received: by 10.82.126.19 with SMTP id y19mr852060buc; Thu, 26 Oct 2006 09:52:04 -0700 (PDT) Received: by 10.49.29.19 with HTTP; Thu, 26 Oct 2006 09:52:04 -0700 (PDT) Message-ID: Date: Thu, 26 Oct 2006 18:52:04 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Adding POST capability to atom:link In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 2006/10/26, Gopalan Sri: > action="POST"> > > > > > I hope such a thing won't ever exist !!! -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Oct 26 13:47:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9KM-0007WB-G2 for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 13:47:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9JO-0006MG-9W for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 13:46:43 -0400 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 k9QHNLhT068800; Thu, 26 Oct 2006 10:23: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 k9QHNLTQ068799; Thu, 26 Oct 2006 10:23: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 ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QHNHkg068781 for ; Thu, 26 Oct 2006 10:23:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by ug-out-1314.google.com with SMTP id 36so460329uga for ; Thu, 26 Oct 2006 10:23:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Xmz1qhNDl7jcyW1OX91kszYE7FUPWI1noq8pHQLZw6Yd5OFr8DCXFNJ6gJtxow3UE4J98T4A33MkUlYZEDp5qLXlzHems6LDTrhAg+tLim+JRHU3bvO7e0zaQ/jgPXgSFpSSPfQp7sW38jHZgpIjTqAXoP3O5HXPg7jxtJeetfI= Received: by 10.82.123.16 with SMTP id v16mr878319buc; Thu, 26 Oct 2006 10:23:16 -0700 (PDT) Received: from ?192.168.1.101? ( [67.181.218.96]) by mx.google.com with ESMTP id 6sm5511388wrh.2006.10.26.10.23.15; Thu, 26 Oct 2006 10:23:15 -0700 (PDT) Message-ID: <4540EEFD.4040201@gmail.com> Date: Thu, 26 Oct 2006 10:23:09 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Thomas Broyer CC: Atom-Syntax Subject: Re: Adding POST capability to atom:link References: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> In-Reply-To: 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: 7d33c50f3756db14428398e2bdedd581 +1. This would not, IMHO, be a good thing for Atom. Feel free to define an extension if you think it would be good. Implementations that find it useful could choose to support it but I doubt you'll find many. - James Thomas Broyer wrote: > > 2006/10/26, Gopalan Sri: >> > action="POST"> >> >> >> >> >> > > I hope such a thing won't ever exist !!! > From owner-atom-syntax@mail.imc.org Thu Oct 26 14:13:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9ja-0006cn-Ue for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 14:13:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9jZ-00031W-Hf for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 14:13:42 -0400 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 k9QHl05C073990; Thu, 26 Oct 2006 10: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 k9QHl0e5073989; Thu, 26 Oct 2006 10: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 smtpout.mac.com (smtpout.mac.com [17.250.248.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QHkvGS073975 for ; Thu, 26 Oct 2006 10:47:00 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id k9QHktqL021093; Thu, 26 Oct 2006 10:46:55 -0700 (PDT) Received: from [10.226.29.184] (ip-80-226-210-233.vodafone-net.de [80.226.210.233]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id k9QHkZO2002390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 10:46:52 -0700 (PDT) In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> References: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: Adding POST capability to atom:link Date: Thu, 26 Oct 2006 19:46:35 +0200 To: Gopalan Sri X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Gopalan, On 26.10.2006, at 18:24, Gopalan Sri wrote: > > Hello, > > I am trying to use opensearch to do some paging of my search > results and > I have a question regard adding POST capabilities to the atom:link > construct. > atom link is not the appropriate place to do something like this. The issue of the server telling the client what resources implement POST is addressed by the Atom Publishing Protocol[1] in the form of collections. If you need to communicate more details, you'd have to use an extension such as atompub-features[2] (its intention though is to enable services to declare behavioural aspects of a collection and not to declare an input form but atompub-feature's controls can be used much like a forms language). HTH, Jan [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub- protocol-11.txt [2] http://www.ietf.org/internet-drafts/draft-snell-atompub- feature-01.txt From owner-atom-syntax@mail.imc.org Thu Oct 26 14:24:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9tY-0000dQ-KB for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 14:24:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9tQ-0004mf-7f for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 14:24:00 -0400 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 k9QHwsWb076325; Thu, 26 Oct 2006 10:58: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 k9QHwsq1076324; Thu, 26 Oct 2006 10:58: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9QHwqYr076297 for ; Thu, 26 Oct 2006 10:58:53 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Oct 2006 17:58:46 -0000 Received: from xdsl-81-173-173-24.netcologne.de (EHLO klangraum) [81.173.173.24] by mail.gmx.net (mp029) with SMTP; 26 Oct 2006 19:58:46 +0200 X-Authenticated: #163624 Date: Thu, 26 Oct 2006 19:58:45 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Adding POST capability to atom:link Message-ID: <20061026175845.GR25343@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> User-Agent: Mutt/1.4.2.1i Organization: haphazard 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 k9QHwsWb076325 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 * Gopalan Sri [2006-10-26 18:50]: > The information I want to pass back to the server is complex in > nature and makes sense to capture in XML. My question is > whether or not there are any thoughts or plans to extend the > atom:link contruct to support something like this: My answer is that the element is called `link` and you=E2=80=99re asking for something other than a link. I certainly hope that clients will never ever be expected to issue anything other than GET in order to dereference a link. If you describe the nature of the task you want to perform, someone might be able to suggest a better mechanism for expressing it. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Oct 26 15:22:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAoM-0005A4-Py for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 15:22:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdAnm-0004Pw-Lp for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 15:22:09 -0400 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 k9QJ5JX9090434; Thu, 26 Oct 2006 12:05: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 k9QJ5Ja4090433; Thu, 26 Oct 2006 12:05: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 smtpout.mac.com (smtpout.mac.com [17.250.248.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QJ5IZb090426 for ; Thu, 26 Oct 2006 12:05:18 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id k9QJ7L8h026128; Thu, 26 Oct 2006 12:07:21 -0700 (PDT) Received: from [85.182.71.137] (e182071137.adsl.alicedsl.de [85.182.71.137]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id k9QJ561S013025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 12:05:15 -0700 (PDT) In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> References: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-9-1046197838 Message-Id: <44CB8FD6-FBC9-41C0-93B7-FC6FDD1BCBF6@mac.com> Cc: atom-syntax@imc.org From: Jan Algermissen Subject: Re: Adding POST capability to atom:link Date: Thu, 26 Oct 2006 21:05:07 +0200 To: Gopalan Sri X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 --Apple-Mail-9-1046197838 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 26.10.2006, at 18:24, Gopalan Sri wrote: > to support > something like this: > > action="POST"> > > > > > If I understand this correctly, you intent to parameterize the request to go to the next page; since your parameters seem to be too complex to but them into the query string, you thought about using POST - yes? If so, this is bad practice anyhow, since you loose all the benefits of GET. Jan --Apple-Mail-9-1046197838 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 26.10.2006, at = 18:24, Gopalan Sri wrote:

to support

something like = this:


<link rel=3D"next" href=3D"http://example.com/" = type=3D"application/atom+xml"

action=3D"POST">

=A0 =A0 = <parameter name=3D"q">

=A0 =A0 =A0 =A0 = <xxx:Payload/>

=A0 =A0 = </parameter>

=A0 =A0 = <parameter name=3D"blah" value=3D"blah"/>

</link>

=

If I understand this correctly, you intent = to parameterize the request to go to the next page; since your = parameters
seem to be too complex to but them into the query = string, you thought about using POST - yes?

If so, this is bad practice = anyhow, since you loose all the benefits of GET.

Jan
= --Apple-Mail-9-1046197838-- From owner-atom-syntax@mail.imc.org Thu Oct 26 15:23:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAoN-00054Q-Ec for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 15:22:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdAni-0004OP-38 for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 15:22:03 -0400 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 k9QIx0Ao088690; Thu, 26 Oct 2006 11:59: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 k9QIx0li088689; Thu, 26 Oct 2006 11:59: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 smtpout.mac.com (smtpout.mac.com [17.250.248.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QIwvCt088673 for ; Thu, 26 Oct 2006 11:58:59 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id k9QIwu1D006906; Thu, 26 Oct 2006 11:58:56 -0700 (PDT) Received: from [85.182.71.137] (e182071137.adsl.alicedsl.de [85.182.71.137]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id k9QIwk1g009857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 11:58:54 -0700 (PDT) In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> References: <01C6BC77CDCE28489B9644BF6D5C08DB0131AF9D@MCLNEXVS01.resource.ds.bah.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30B2CA41-E7F2-44E2-B9B2-72515A01EA0D@mac.com> Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Jan Algermissen Subject: Re: Adding POST capability to atom:link Date: Thu, 26 Oct 2006 20:58:48 +0200 To: Gopalan Sri X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On 26.10.2006, at 18:24, Gopalan Sri wrote: > > Hello, > > I am trying to use opensearch to do some paging of my search > results and > I have a question regard adding POST capabilities to the atom:link > construct. Gopalan, could you reveal the use case that makes you think you need the POST capabilities? Jan > > The information I want to pass back to the server is complex in nature > and makes sense to capture in XML. My question is whether or not > there > are any thoughts or plans to extend the atom:link contruct to support > something like this: > > action="POST"> > > > > > > > Thanks. > Sri Gopalan > Booz Allen Hamilton > Office: Allen 147 > Tel: 703.377.1404 > Mobile: 703.395.4057 > From owner-atom-syntax@mail.imc.org Thu Oct 26 16:00:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMw-00021t-Mi for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 15:58:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBBk-00074P-QW for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 15:46:59 -0400 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 k9QJV9fQ095591; Thu, 26 Oct 2006 12:31: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 k9QJV9uo095590; Thu, 26 Oct 2006 12:31: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 mclniron02-ext.bah.com (mclniron02-ext.bah.com [156.80.1.73]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QJV8Ou095584 for ; Thu, 26 Oct 2006 12:31:08 -0700 (MST) (envelope-from gopalan_sri@bah.com) Received: from bahmail.bah.com (HELO mclnexbh02.resource.ds.bah.com) ([156.80.7.152]) by mclniron02-ext.bah.com with ESMTP; 26 Oct 2006 15:31:08 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.152 X-IronPort-AV: i="4.09,362,1157342400"; d="scan'208,217"; a="79084373:sNHT31000096" Received: from MCLNEXVS01.resource.ds.bah.com ([156.80.7.104]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 15:31:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F935.48CB1306" Subject: RE: Adding POST capability to atom:link Date: Thu, 26 Oct 2006 15:31:07 -0400 Message-ID: <01C6BC77CDCE28489B9644BF6D5C08DB0131B066@MCLNEXVS01.resource.ds.bah.com> In-Reply-To: <44CB8FD6-FBC9-41C0-93B7-FC6FDD1BCBF6@mac.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adding POST capability to atom:link Thread-Index: Acb5Ma19kJOxD59iTnG4Jnnd7+10rQAASI/w From: "Gopalan Sri" To: X-OriginalArrivalTime: 26 Oct 2006 19:31:08.0141 (UTC) FILETIME=[491629D0:01C6F935] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F935.48CB1306 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you all for your quick response. I apologize for the weak description of my problem. Jan, you are correct in your assessment that I wish to parameterize my request to go to the next page because my parameters are too complex to represent in a query string. Currently, we are representing our parameter in XML. The reasoning behind this is that we are trying to support an enterprise search operation using a SOAP and REST interfaces. Since we have to encode the request in XML for the SOAP interface, we were hoping to reuse that XML object within our REST based interfaces as well. =20 We are using Atom to capture the results of enterprise search. The problem I encounter arises when we start thinking about the paging of results. For RESTful access to our services, we are trying to use open source/commercial Atom readers that support Open Search. The recommendations laid out by the OpenSearch 1.1 specification (http://www.opensearch.org/Specifications/OpenSearch/1.1#Example_of_Open Search_response_elements_in_Atom_1.0) suggest implementing paging with elements using specific values for @rel (e.g. self, first, previous, next, last). Right now I am trying to figure out how I can still follow their guidance while managing the fact that my parameter cannot easily be encoded as a regular query string. Any thoughts would be appreciated. Thanks for your time. Sri=20 ________________________________ From: Jan Algermissen [mailto:algermissen1971@mac.com]=20 Sent: Thursday, October 26, 2006 3:05 PM To: Gopalan Sri Cc: atom-syntax@imc.org Subject: Re: Adding POST capability to atom:link On 26.10.2006, at 18:24, Gopalan Sri wrote: to support something like this: =09 =09 If I understand this correctly, you intent to parameterize the request to go to the next page; since your parameters seem to be too complex to but them into the query string, you thought about using POST - yes? If so, this is bad practice anyhow, since you loose all the benefits of GET. Jan ------_=_NextPart_001_01C6F935.48CB1306 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you all for = your quick=20 response.  I apologize for the weak description of my=20 problem.

Jan, you are correct = in your=20 assessment that I wish to parameterize my request to go to the next page = because=20 my parameters are too complex to represent in a query string.  = Currently,=20 we are representing our parameter in XML.  The reasoning behind = this is=20 that we are trying to support an enterprise search operation using a = SOAP and=20 REST interfaces.  Since we have to encode the request in XML for = the SOAP=20 interface, we were hoping to reuse that XML object within our REST based = interfaces as well. 

We are using Atom to = capture the=20 results of enterprise search.  The problem I encounter arises when = we start=20 thinking about the paging of results.  For RESTful access to our = services,=20 we are trying to use open source/commercial Atom readers that support = Open=20 Search.  The  recommendations laid out by the OpenSearch = 1.1=20 specification  (http://www.opensearch.org/Spe= cifications/OpenSearch/1.1#Example_of_OpenSearch_response_elements_in_Ato= m_1.0)  suggest implementing paging = with=20 <atom:link/> elements using specific values for @rel (e.g. self, = first,=20 previous, next, last).  Right now I am trying to figure out = how I can=20 still follow their guidance while managing the fact that=20  my parameter cannot easily be encoded as a regular = query=20 string.

Any thoughts would be = appreciated.  Thanks for your time.

Sri 


From: Jan Algermissen=20 [mailto:algermissen1971@mac.com]
Sent: Thursday, October 26, = 2006=20 3:05 PM
To: Gopalan Sri
Cc:=20 atom-syntax@imc.org
Subject: Re: Adding POST capability to=20 atom:link


On 26.10.2006, at 18:24, Gopalan Sri wrote:

to support

something like this:


<link rel=3D"next" href=3D"http://example.com/"=20 type=3D"application/atom+xml"

action=3D"POST">

    = <parameter=20 name=3D"q">

      =  =20 <xxx:Payload/>

   =20 </parameter>

    = <parameter=20 name=3D"blah" value=3D"blah"/>

</link>


If I understand this correctly, you intent to parameterize the = request to=20 go to the next page; since your parameters
seem to be too complex to but them into the query string, you = thought about=20 using POST - yes?

If so, this is bad practice anyhow, since you loose all the = benefits of=20 GET.

Jan
------_=_NextPart_001_01C6F935.48CB1306-- From owner-atom-syntax@mail.imc.org Thu Oct 26 16:15:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBdC-0005nH-9s for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 16:15:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBcu-0001k9-IW for atompub-archive@lists.ietf.org; Thu, 26 Oct 2006 16:15:14 -0400 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 k9QK2LT1002036; Thu, 26 Oct 2006 13:02: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 k9QK2LTX002035; Thu, 26 Oct 2006 13:02: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 smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QK2I40002027 for ; Thu, 26 Oct 2006 13:02:20 -0700 (MST) (envelope-from algermissen1971@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id k9QK2HvV015585; Thu, 26 Oct 2006 13:02:17 -0700 (PDT) Received: from [85.182.71.137] (e182071137.adsl.alicedsl.de [85.182.71.137]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id k9QK290N005586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 13:02:12 -0700 (PDT) In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131B066@MCLNEXVS01.resource.ds.bah.com> References: <01C6BC77CDCE28489B9644BF6D5C08DB0131B066@MCLNEXVS01.resource.ds.bah.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-10-1049620987 Message-Id: <6FEA78B3-F2A9-49C3-911C-488752FDEC9E@mac.com> Cc: atom-syntax@imc.org From: Jan Algermissen Subject: Re: Adding POST capability to atom:link Date: Thu, 26 Oct 2006 22:02:10 +0200 To: Gopalan Sri X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.6 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b --Apple-Mail-10-1049620987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Gopalan, On 26.10.2006, at 21:31, Gopalan Sri wrote: > Thank you all for your quick response. I apologize for the weak =20 > description of my problem. > > Jan, you are correct in your assessment that I wish to parameterize =20= > my request to go to the next page because my parameters are too =20 > complex to represent in a query string. If you aim to provide a REST interface, do not mimick a query =20 interface (at least not a complex one). Think of your 'asset space' =20 in terms of pre-defined, useful collections that you expose as =20 resources (feeds) and provide light weight query interfaces to them =20 that fit with GET requests. Think in terms of browsing and drilling-down; REST interfaces guide =20 the client into the content instead of assuming the knowledge to =20 construct a query does reside in the client. This, BTW, avoids coupling your clients to the local data model =20 specifics. Jan "The Web doesn=92t do generic query" > Currently, we are representing our parameter in XML. The reasoning =20= > behind this is that we are trying to support an enterprise search =20 > operation using a SOAP and REST interfaces. Since we have to =20 > encode the request in XML for the SOAP interface, we were hoping to =20= > reuse that XML object within our REST based interfaces as well. > > We are using Atom to capture the results of enterprise search. The =20= > problem I encounter arises when we start thinking about the paging =20 > of results. For RESTful access to our services, we are trying to =20 > use open source/commercial Atom readers that support Open Search. =20 > The recommendations laid out by the OpenSearch 1.1 specification =20 > (http://www.opensearch.org/Specifications/OpenSearch/=20 > 1.1#Example_of_OpenSearch_response_elements_in_Atom_1.0) suggest =20 > implementing paging with elements using specific =20 > values for @rel (e.g. self, first, previous, next, last). Right =20 > now I am trying to figure out how I can still follow their guidance =20= > while managing the fact that my parameter cannot easily be encoded =20= > as a regular query string. > > Any thoughts would be appreciated. Thanks for your time. > > Sri > > > From: Jan Algermissen [mailto:algermissen1971@mac.com] > Sent: Thursday, October 26, 2006 3:05 PM > To: Gopalan Sri > Cc: atom-syntax@imc.org > Subject: Re: Adding POST capability to atom:link > > > On 26.10.2006, at 18:24, Gopalan Sri wrote: > >> to support >> something like this: >> >> > +xml" >> action=3D"POST"> >> >> >> >> >> > > If I understand this correctly, you intent to parameterize the =20 > request to go to the next page; since your parameters > seem to be too complex to but them into the query string, you =20 > thought about using POST - yes? > > If so, this is bad practice anyhow, since you loose all the =20 > benefits of GET. > > Jan --Apple-Mail-10-1049620987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Gopalan,

On = 26.10.2006, at 21:31, Gopalan Sri wrote:

Thank you all for your = quick response.=A0 I apologize for the weak description of my = problem.

Jan, you are correct in your assessment = that I wish to parameterize my request to go to the next page because my = parameters are too complex to represent in a query = string.

If you aim to provide a = REST interface, do not mimick a query interface (at least not a complex = one). Think of your 'asset space' in terms of pre-defined, useful = collections that you expose as resources (feeds) and provide light = weight query interfaces to them that fit with GET = requests.
Think in terms of browsing and drilling-down; REST = interfaces guide the client into the content instead of assuming the = knowledge to construct
a query does reside in the = client.
This, BTW, avoids coupling your clients to the local = data model specifics.


Jan

"The Web doesn=92t do = generic query"


= Currently, we are representing our parameter in XML.=A0 The reasoning = behind this is that we are trying to support an enterprise search = operation using a SOAP and REST interfaces.=A0 Since we have to encode = the request in XML for the SOAP interface, we were hoping to reuse that = XML object within our REST based interfaces as well.=A0 =

We are using Atom to capture the results of = enterprise search.=A0 The problem I encounter arises when we start = thinking about the paging of results.=A0 For RESTful access to our = services, we are trying to use open source/commercial Atom readers that = support Open Search.=A0=A0The=A0 recommendations laid out by the OpenSearch = 1.1 specification=A0 (http://www.opensearch.org/Speci= fications/OpenSearch/1.1#Example_of_OpenSearch_response_elements_in_Atom_1= .0)=A0 suggest implementing paging with = <atom:link/> elements using specific values for @rel (e.g. self, = first, previous, next,=A0last).=A0 Right now I am trying to figure out = how I can still follow their guidance while managing the fact that = =A0my=A0parameter=A0cannot easily=A0be encoded as a regular query = string.

Any thoughts would be appreciated.=A0 = Thanks for=A0your time.

Sri=A0


=
From: Jan = Algermissen [mailto:algermissen1971@mac.com= ]
Sent: Thursday, October 26, 2006 3:05 PM
To: = Gopalan Sri
Cc: atom-syntax@imc.org
Subject:= Re: Adding POST capability to atom:link

=

On 26.10.2006, at 18:24, Gopalan Sri = wrote:

to support
something like this:

<link = rel=3D"next" href=3D"http://example.com/" = type=3D"application/atom+xml"
action=3D"POST">
=A0 =A0 <parameter = name=3D"q">
=A0 =A0 =A0 =A0 = <xxx:Payload/>
=A0 =A0 = </parameter>
=A0 =A0 <parameter = name=3D"blah" value=3D"blah"/>
</link>

If I = understand this correctly, you intent to parameterize the request to go = to the next page; since your parameters
seem to be too = complex to but them into the query string, you thought about using POST = - yes?

If = so, this is bad practice anyhow, since you loose all the benefits of = GET.

=
Jan

= --Apple-Mail-10-1049620987-- From owner-atom-syntax@mail.imc.org Fri Oct 27 02:47:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLUu-0001Eg-Bs for atompub-archive@lists.ietf.org; Fri, 27 Oct 2006 02:47:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdLUo-0001tt-WD for atompub-archive@lists.ietf.org; Fri, 27 Oct 2006 02:47:19 -0400 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 k9R6OWN3029786; Thu, 26 Oct 2006 23:24: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 k9R6OWT9029785; Thu, 26 Oct 2006 23:24: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9R6OUcO029766 for ; Thu, 26 Oct 2006 23:24:31 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so1203247nfa for ; Thu, 26 Oct 2006 23:24:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ISWKuo7BHUATJPDLeCSPgWpfKCskyeXR06wctXR2X+4eUDTcfSAjAkMDnlaaszSEemBlrIV9xmdHRL7aV5Fdbns+foelO2atsG+kSRM90MA8wbq1PrOiBlsxuhIR/REIuF9Vnllrx1Xj2ImyyE+3PGD4jxtnAcU1lBR2qHNCK6E= Received: by 10.49.80.12 with SMTP id h12mr282365nfl; Thu, 26 Oct 2006 23:24:29 -0700 (PDT) Received: by 10.49.29.19 with HTTP; Thu, 26 Oct 2006 23:24:29 -0700 (PDT) Message-ID: Date: Fri, 27 Oct 2006 08:24:29 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Adding POST capability to atom:link In-Reply-To: <01C6BC77CDCE28489B9644BF6D5C08DB0131B066@MCLNEXVS01.resource.ds.bah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44CB8FD6-FBC9-41C0-93B7-FC6FDD1BCBF6@mac.com> <01C6BC77CDCE28489B9644BF6D5C08DB0131B066@MCLNEXVS01.resource.ds.bah.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 2006/10/26, Gopalan Sri: > > Jan, you are correct in your assessment that I wish to parameterize my > request to go to the next page because my parameters are too complex to > represent in a query string. Currently, we are representing our parameter > in XML. The reasoning behind this is that we are trying to support an > enterprise search operation using a SOAP and REST interfaces. Since we have > to encode the request in XML for the SOAP interface, we were hoping to reuse > that XML object within our REST based interfaces as well. > > We are using Atom to capture the results of enterprise search. The problem > I encounter arises when we start thinking about the paging of results. For > RESTful access to our services, we are trying to use open source/commercial > Atom readers that support Open Search. The recommendations laid out by the > OpenSearch 1.1 specification > (http://www.opensearch.org/Specifications/OpenSearch/1.1#Example_of_OpenSearch_response_elements_in_Atom_1.0) > suggest implementing paging with elements using specific > values for @rel (e.g. self, first, previous, next, last). Right now I am > trying to figure out how I can still follow their guidance while managing > the fact that my parameter cannot easily be encoded as a regular query > string. > > Any thoughts would be appreciated. Thanks for your time. I think your "search service" should create "temporary resources" and provide URIs for them to use in rel="next" links. A simple implementation is to store an object corresponding to the query parameters within a "Cache" or "Application" server-side object along with a "UniqueID", and then use that id in the URI to identify the query. The object would be removed from the cache/application after some delay of "inactivity". That's pretty easy in ASP.NET developments as the Cache object is provided out-of-the-box; there should be equivalents in the Java world too. -- Thomas Broyer